[Gluster-devel] Idea: Alternate Release process

Fri May 13 08:35:57 UTC 2016

+1 for "Proposed alternative 3 - One LTS every year and non LTS stable release once in every 4 months" as it is more appropriate. 

Regards, 
Poornima 

----- Original Message -----

> From: "Aravinda" <avishwan at redhat.com>
> To: "Kaushal M" <kshlmster at gmail.com>, "Gluster Devel"
> <gluster-devel at gluster.org>
> Sent: Friday, May 13, 2016 1:46:23 PM
> Subject: Re: [Gluster-devel] Idea: Alternate Release process

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160513/0f4559a4/attachment.html>