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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxx >> http://www.gluster.org/mailman/listinfo/gluster-devel >> >> >> >> >> >> _______________________________________________ >> Gluster-devel mailing list >> Gluster-devel@xxxxxxxxxxx >> http://www.gluster.org/mailman/listinfo/gluster-devel > _______________________________________________ > Gluster-users mailing list > Gluster-users@xxxxxxxxxxx > http://www.gluster.org/mailman/listinfo/gluster-users > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
