[Gluster-users] [Gluster-devel] Idea: Alternate Release process

M S Vishwanath Bhat msvbhat at gmail.com
Wed May 18 14:05:57 UTC 2016 

On 13 May 2016 at 13:46, Aravinda <avishwan at redhat.com> wrote:

> Hi,
>
> Based on the discussion in last community meeting and previous discussions,
>
> 1. Too frequent releases are difficult to manage.(without dedicated
> release manager)
> 2. Users wants to see features early for testing or POC.
> 3. Backporting patches to more than two release branches is pain
>
> Enclosed visualizations to understand existing release and support cycle
> and proposed alternatives.
>
> - Each grid interval is 6 months
> - Green rectangle shows supported release or LTS
> - Black dots are minor releases till it is supported(once a month)
> - Orange rectangle is non LTS release with minor releases(Support ends
> when next version released)
>
> Enclosed following images
> 1. Existing Release cycle and support plan(6 months release cycle, 3
> releases supported all the time)
> 2. Proposed alternative 1 - One LTS every year and non LTS stable release
> once in every 2 months
> 3. Proposed alternative 2 - One LTS every year and non LTS stable release
> once in every 3 months
>

+1 for 3rd option. non-LTS stable release on every three months.

Best Regards,
Vishwanath



> 4. Proposed alternative 3 - One LTS every year and non LTS stable release
> once in every 4 months
> 5. Proposed alternative 4 - One LTS every year and non LTS stable release
> once in every 6 months (Similar to existing but only alternate one will
> become LTS)
>
> Please do vote for the proposed alternatives about release intervals and
> LTS releases. You can also vote for the existing plan.
>
> Do let me know if I missed anything.
>
> regards
> Aravinda
>
> On 05/11/2016 12:01 AM, Aravinda wrote:
>
> I couldn't find any solution for the backward incompatible changes. As you
> mentioned this model will not work for LTS.
>
> How about adopting this only for non LTS releases? We will not have
> backward incompatibility problem since we need not release minor updates to
> non LTS releases.
>
> regards
> Aravinda
>
> On 05/05/2016 04:46 PM, Aravinda wrote:
>
>
> regards
> Aravinda
>
> On 05/05/2016 03:54 PM, Kaushal M wrote:
>
> On Thu, May 5, 2016 at 11:48 AM, Aravinda <avishwan at redhat.com>
> <avishwan at redhat.com> wrote:
>
> Hi,
>
> Sharing an idea to manage multiple releases without maintaining
> multiple release branches and backports.
>
> This idea is heavily inspired by the Rust release model(you may feel
> exactly same except the LTS part). I think Chrome/Firefox also follows
> the same model.
>
> http://blog.rust-lang.org/2014/10/30/Stability.html
>
> Feature Flag:
> --------------
> Compile time variable to prevent compiling featurerelated code when
> disabled. (For example, ./configure--disable-geo-replication
> or ./configure --disable-xml etc)
>
> Plan
> -----
> - Nightly build with all the features enabled(./build --nightly)
>
> - All new patches will land in Master, if the patch belongs to a
>    existing feature then it should be written behind that feature flag.
>
> - If a feature is still work in progress then it will be only enabled in
>    nightly build and not enabled in beta or stable builds.
>    Once the maintainer thinks the feature is ready for testing then that
>    feature will be enabled in beta build.
>
> - Every 6 weeks, beta branch will be created by enabling all the
>    features which maintainers thinks it is stable and previous beta
>    branch will be promoted as stable.
>    All the previous beta features will be enabled in stable unless it
>    is marked as unstable during beta testing.
>
> - LTS builds are same as stable builds but without enabling all the
>    features. If we decide last stable build will become LTS release,
>    then the feature list from last stable build will be saved as
>    `features-release-<NUM>.yaml`, For example:
>    features-release-3.9.yaml`
>    Same feature list will be used while building minor releases for the
>    LTS. For example, `./build --stable --features
> features-release-3.8.yaml`
>
> - Three branches, nightly/master, testing/beta, stable
>
> To summarize,
> - One stable release once in 6 weeks
> - One Beta release once in 6 weeks
> - Nightly builds every day
> - LTS release once in 6 months or 1 year, Minor releases once in 6 weeks.
>
> Advantageous:
> -------------
> 1. No more backports required to different release branches.(only
>     exceptional backports, discussed below)
> 2. Non feature Bugfix will never get missed in releases.
> 3. Release process can be automated.
> 4. Bugzilla process can be simplified.
>
> Challenges:
> ------------
> 1. Enforcing Feature flag for every patch
> 2. Tests also should be behind feature flag
> 3. New release process
>
> Backports, Bug Fixes and Features:
> ----------------------------------
> - Release bug fix - Patch only to Master, which will be available in
>    next beta/stable build.
> - Urgent bug fix - Patch to Master and Backport to beta and stable
>    branch, and early release stable and beta build.
> - Beta bug fix - Patch to Master and Backport to Beta branch if urgent.
> - Security fix - Patch to Master, Beta and last stable branch and build
>    all LTS releases.
> - Features - Patch only to Master, which will be available in
>    stable/beta builds once feature becomes stable.
>
> FAQs:
> -----
> - Can a feature development take more than one release cycle(6 weeks)?
> Yes, the feature will be enabled only in nightly build and not in
> beta/stable builds. Once the feature is complete mark it as
> stable so that it will be included in next beta build and stable
> build.
>
>
> ---
>
> Do you like the idea? Let me know what you guys think.
>
> This reduces the number of versions that we need to maintain, which I
> like.
> Having official test (beta) releases should help get features out to
> testers hand faster,
> and get quicker feedback.
>
> One thing that's still not quite clear to is the issue of backwards
> compatibility.
> I'm still thinking it thorough and don't have a proper answer to this yet.
> Would a new release be backwards compatible with the previous release?
> Should we be maintaining compatibility with LTS releases with the
> latest release?
>
> Each LTS release will have seperate list of features to be enabled. If we
> make any breaking changes(which are not backward compatible) then it will
> affect LTS releases as you mentioned. But we should not break compatibility
> unless it is major version change like 4.0. I have to workout how we can
> handle backward incompatible changes.
>
> With our current strategy, we at least have a long term release branch,
> so we get some guarantees of compatibility with releases on the same
> branch.
>
> As I understand the proposed approach, we'd be replacing a stable
> branch with the beta branch.
> So we don't have a long-term release branch (apart from LTS).
>
> Stable branch is common for LTS releases also. Builds will be different
> using different list of features.
>
> Below example shows stable release once in 6 weeks, and two LTS releases
> in 6 months gap(3.8 and 3.12)
>
> LTS 1 : 3.8    3.8.1  3.8.2  3.8.3   3.8.4   3.8.5...
> LTS 2 :                              3.12    3.12.1...
> Stable: 3.8    3.9    3.10   3.11    3.12    3.13...
>
> A user would be upgrading from one branch to another for every release.
> Can we sketch out how compatibility would work in this case?
>
> User will not upgrade from one branch to other branch, If user interested
> in stable channel then upgrade once in 6 weeks. (Same as minor update in
> current release style)
>
>
> This approach work well for projects like Chromium and Firefox, single
> system apps
>   which generally don't need to be compatible with the previous release.
> I don't understand how the Rust  project uses this (I am yet to read
> the linked blog post),
> as it requires some sort of backwards compatibility. But it too is a
> single system app,
> and doesn't have the compatibility problems we face.
>
> Gluster is a distributed system, that can involve multiple different
> versions interacting with each other.
> This is something we need to think about.
>
> I need to think about compatibility, What new problems about the
> compatibility with this approach compared to our existing release plan?
>
>
> We could work out some sort of a solution for this though.
> It might be something very obvious I'm missing right now.
>
> ~kaushal
>
> --
> regards
> Aravinda
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>
>
>
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20160518/85f2026c/attachment.html>

More information about the Gluster-users mailing list