[Gluster-users] [Gluster-devel] Idea: Alternate Release process
Shyam
srangana at redhat.com
Fri May 20 14:00:34 UTC 2016
On 05/19/2016 10:25 PM, Pranith Kumar Karampuri wrote:
> Once every 3 months i.e. option 3 sounds good to me.
+1 from my end.
Every 2 months seems to be a bit too much, 4 months is still fine, but
gives us 1 in 3 to pick the LTS, I like 1:4 odds better for the LTS,
hence the 3 months (or 'alternative 2').
>
> Pranith
>
> On Fri, May 13, 2016 at 1:46 PM, Aravinda <avishwan at redhat.com
> <mailto: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
> 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>
>>>> <mailto: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 <mailto:Gluster-devel at gluster.org>
>>>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org <mailto: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
>
More information about the Gluster-users
mailing list