M S Vishwanath Bhat
2016-May-18 14:05 UTC
[Gluster-users] [Gluster-devel] Idea: Alternate Release process
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>