[Gluster-devel] Idea: Alternate Release process

Aravinda avishwan at redhat.com
Tue May 10 18:31:47 UTC 2016


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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160511/947ed896/attachment-0001.html>


More information about the Gluster-devel mailing list