Re: [Gluster-devel] Idea: Alternate Release process

[Shyam]

On 05/29/2016 10:08 PM, Sankarshan Mukhopadhyay wrote:

On Fri, May 20, 2016 at 7:30 PM, Shyam  wrote:

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').





It would perhaps be worthwhile to extend this release timeline/cadence
discussion into (a) End-of-Life definition and invocation (b) whether
a 'long term support' (assuming that is what LTS is) is of essentially
any value to users of GlusterFS.


I see it as a couple of things here,
- We call one of the intermediate 3 month updates an LTS based on its 
stability and quality. This should provide a clean upgrade from the 
previous upgrade (as clean as possible at least, and should/could be a 
gating factor).


- The use of "one of the" above, is explicit so that we continue the 3 
month cadence on update releases, but say the 4th update does not make 
the cut then the 5th can, hence have the flexibility on the LTS


Unless we want to be extremely stringent on this.

Next, I would expect that this [1] page would be updated with this 
decision, either as soon as 3.8 is released or earlier than that.




(b) especially can be (and perhaps should be) addressed by predictable
and tested upgrade paths to ensure that users are able to get to newer
releases without much hassles.



[1] http://www.gluster.org/community/release-schedule/
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Idea: Alternate Release process

[Oleksandr Natalenko]

30.05.2016 05:08, Sankarshan Mukhopadhyay написав:

It would perhaps be worthwhile to extend this release timeline/cadence
discussion into (a) End-of-Life definition and invocation (b) whether
a 'long term support' (assuming that is what LTS is) is of essentially
any value to users of GlusterFS.

(b) especially can be (and perhaps should be) addressed by predictable
and tested upgrade paths to ensure that users are able to get to newer
releases without much hassles.


I believe 3.7 should be LTS with EOL in 1 year at least because it is 
the last branch released before changes to release process were 
committed.

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Idea: Alternate Release process

[Sankarshan Mukhopadhyay]

On Fri, May 20, 2016 at 7:30 PM, Shyam  wrote:
> 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').
>
>>

It would perhaps be worthwhile to extend this release timeline/cadence
discussion into (a) End-of-Life definition and invocation (b) whether
a 'long term support' (assuming that is what LTS is) is of essentially
any value to users of GlusterFS.

(b) especially can be (and perhaps should be) addressed by predictable
and tested upgrade paths to ensure that users are able to get to newer
releases without much hassles.

>> On Fri, May 13, 2016 at 1:46 PM, 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 
>  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 

Re: [Gluster-devel] Idea: Alternate Release process

[Vijay Bellur]

On Fri, May 20, 2016 at 10:00 AM, Shyam  wrote:
> 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').
>


The option to have non-LTS releases once every 3 months seems to have
gathered the most votes in this poll. Hence let us get that rolling
and tentatively target 3.9 GA for 3 months after 3.8 LTS is out.

Cheers,
Vijay
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Idea: Alternate Release process

[Shyam]

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 > 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 
 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-.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.

Re: [Gluster-devel] Idea: Alternate Release process

[M S Vishwanath Bhat]

On 13 May 2016 at 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
>

+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 
>  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-.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 

Re: [Gluster-devel] Idea: Alternate Release process

[Vijay Bellur]

[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  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  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-.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
>

Re: [Gluster-devel] Idea: Alternate Release process

[Jiffin Tony Thottan]

+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  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-.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.

Re: [Gluster-devel] Idea: Alternate Release process

[Poornima Gurusiddaiah]

+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" <avish...@redhat.com>
> To: "Kaushal M" <kshlms...@gmail.com>, "Gluster Devel"
> <gluster-devel@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 <avish...@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 

Re: [Gluster-devel] Idea: Alternate Release process

[Aravinda]

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  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-.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 

Re: [Gluster-devel] Idea: Alternate Release process

[Oleksandr Natalenko]

My 2 cents on timings etc.

Rationale:

1. deliver new features to users as fast as possible to get the feedback;
2. leave an option of using LTS branch for those who do not want update too 
often.

Definition:

* "stable release" — .0 tag that receives critical bugfixes and security 
updates for 16 weeks;
* "LTS" — .0 tag that receives critical bugfixes and security updates for 1 
year;

New release happens every 8 weeks. Those 8 weeks include:

* merge window for 3 weeks, during this time all ready features get merged 
into master;
* feature freeze on -rc1 tagging;
* 5 weeks of testing, bugfixing and preparing new features;
* tagging .0 stable release.

Example (imaginary versions and dates):

March 1 — 5.0 release, merge window opens
March 22 — 6.0-rc1 release, merge window closes, feature freeze, new -rc each 
week
May 1 — 6.0 release, merge window opens, 5.0 still gets fixes
May 22 — 7.0-rc1 release
July 1 — 7.0 release, merge window closes, no more fixes for 5.0, 6.0 still 
gets fixes
...
September 1 — 8.0 release, LTS, EOT is Sep 1, next year.
...

Backward compatibility should be guaranteed during the time between two 
consecutive LTSes by excessive using of op-version. The user should have a 
possibility to upgrade from one LTS to another preferably with no downtime. 
LTS+1 is not guaranteed to backward compatible with LTS-1.

Pros:

* frequent releases with new features that do not break backward 
compatibility;
* max 2 stable branches supported simultaneously;
* guaranteed LTS branch with guaranteed upgrade to new LTS.

Cons:

* no idea what to do with things that break backward compatibility and that 
couldn't be implemented within op-version constraints (except postponing them 
for too much).
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Idea: Alternate Release process

[Aravinda]

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  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-.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 

Re: [Gluster-devel] Idea: Alternate Release process

[Aravinda]

regards
Aravinda

On 05/05/2016 03:54 PM, Kaushal M wrote:

On Thu, May 5, 2016 at 11:48 AM, Aravinda  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-.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.83.8.1  3.8.2  3.8.3   3.8.4   3.8.5...
LTS 2 :  3.123.12.1...
Stable: 3.83.93.10   3.113.123.13...

A user would be upgrading from one branch to another for every release.
Can we 

Re: [Gluster-devel] Idea: Alternate Release process

[Kaushal M]

On Thu, May 5, 2016 at 11:48 AM, Aravinda  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-.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?
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).
A user would be upgrading from one branch to another for every release.
Can we sketch out how compatibility would work in this case?

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.

We could work out some sort of a solution for this