[Gluster-devel] Idea: Alternate Release process
Jiffin Tony Thottan
jthottan at redhat.com
Tue May 17 12:42:13 UTC 2016
+1 Proposed alternative 2 - One LTS every year and non LTS stable
release once in every 3 months
On 13/05/16 13:46, Aravinda 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160517/b6089a60/attachment-0001.html>
More information about the Gluster-devel
mailing list