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

Atin Mukherjee amukherj at redhat.com
Wed May 18 18:16:57 UTC 2016 

A bit late but better than never. My vote is for option 2.

~Atin

On 05/18/2016 07:19 PM, Vijay Bellur wrote:
> [Adding gluster-users]
> 
> I would like to wrap this poll by the next community meeting on 25th
> May. Can you please weigh in with your opinions on the options
> provided by Aravinda?
> 
> Thanks!
> Vijay
> 
> 
> On Fri, May 13, 2016 at 4:16 AM, 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
>> 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> 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
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
>

More information about the Gluster-users mailing list