[Gluster-devel] Idea: Alternate Release process

Shyam srangana at redhat.com
Fri May 20 14:00:34 UTC 2016


On 05/19/2016 10:25 PM, Pranith Kumar Karampuri wrote:
> Once every 3 months i.e. option 3 sounds good to me.

+1 from my end.

Every 2 months seems to be a bit too much, 4 months is still fine, but 
gives us 1 in 3 to pick the LTS, I like 1:4 odds better for the LTS, 
hence the 3 months (or 'alternative 2').

>
> Pranith
>
> On Fri, May 13, 2016 at 1:46 PM, Aravinda <avishwan at redhat.com
> <mailto: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
>     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>
>>>>     <mailto: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 <mailto:Gluster-devel at gluster.org>
>>>>>     http://www.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>
>
>     _______________________________________________
>     Gluster-devel mailing list
>     Gluster-devel at gluster.org <mailto: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
>


More information about the Gluster-devel mailing list