[DISCUSS] 5.0.0 and 6.0.0

[John Burwell <jo...@shapeblue.com>]

All,

We have been discussing whether or not the next release would introduce the need to increment the major revision number from 4 to 5 (i.e. become 5.0.0).  While I think we are very close to the time to have a 5.0.0 release, I don’t think the next release will introduce any backwards compatible changes that necessitate.  However, Wido has brought two important questions — What are our goals for a 5.0.0 release? When do we think we should target its release?  I think we should address and gain consensus on these issues now rather than allow circumstances to answer them for us.

Since I joined the community (back in the 4.1.0 days), 5.0.0 was a mythical, someday release when CloudStack would have a perfect architecture, build process, etc. -- a unicorn jumping a rainbow.  I realize that I have fallen into the trap of seeing 5.0.0 as some endpoint of perfection rather than an important milestone in the on-going improvement and evolution of the project.  Thinking it about is the former rather than the later, I realize that we have a legacy cruft that we need to discard in order to move forward and architectural design improvements that we must implement to address emerging infrastructure requirements.  I think we would be wise to separate these two objectives into a 5.0.0 release (cruft removal/breaking refactorings) and 6.0.0 (backwards incompatible architectural redesign).  Not only do I see this approach as a risk mitigation, but also as a way to deliver improvements to users and developers as quickly as possible.

For 5.0.0, my thought is that we would target the following high-level objectives:

* Drop Java7 and adopt Java8 runtime and language features
* Drop support for any hypervisor versions no longer supported by their vendors or communities
* Drop any plugins which are no longer maintained or for which the community has no means to test
* Drop support for any distributions no longer supported by their vendors or communities
* Define an official support matrix for the project
* Adopt a formal policy for sunsetting support of components based on the end-of-life dates set by their vendors or communities
* Refactoring/cleanup of various APIs
* Embedded Jetty/uberjar/unified YAML file configuration

While I am sure there are more clean up items, the focus of the release would be to discard pieces that are in the way on further improvement.

6.0.0 would be released within 9-12 months of 5.0.0 — giving the community time to build atop 5.0.0 to redesign/improve the architecture of the system.

I would like to see 5.0.0 released by the end of 2016 or at the beginning of 2017.  Based on the release plan I previously proposed, we would have the following releases remaining in 2016 and in early 2017: 

* 4.10 releasing on or about 28 August 2016
* 4.11 releasing on or about 23 October 2016
* 4.12 releasing on or about 18 December 2016 
* 4.13 release on or about 5 February 2017

4.12 seems to be the sweet spot in the schedule to cut the 5.0.0 release described above.  It would give us sometime to plan and gain consensus around the changes in both the user and dev communities.  It would also allow the second LTS release to be based on 5.0.0 — allowing both release cycles to take advantage of the reduced support requirements and Java8 language features. Based on this proposal, the releases above would change to the following:

* 4.10 releasing on or about 28 August 2016
* 4.11 releasing on or about 23 October 2016
* 5.0.0 releasing on or about 18 December 2016 
* 5.1.0 release on or about 5 February 2017

6.0.0 would be targeted for release in 4Q2017 — providing 9-12 months to design and implement architectural improvements.

Thoughts?  Other paths to 5.0.0 and beyond?
-John
john.burwell@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue

Re: [DISCUSS] 5.0.0 and 6.0.0

[Daan Hoogland <da...@gmail.com>]

I don't know if your date projections are any good but +1 to the overall
ideas you pose here ,John. As was mentioned in the other thread I would
include API refactor in one of the two (5- or 6.0.0)

On Wed, Jun 15, 2016 at 2:39 AM, John Burwell <jo...@shapeblue.com>
wrote:

> All,
>
> We have been discussing whether or not the next release would introduce
> the need to increment the major revision number from 4 to 5 (i.e. become
> 5.0.0).  While I think we are very close to the time to have a 5.0.0
> release, I don’t think the next release will introduce any backwards
> compatible changes that necessitate.  However, Wido has brought two
> important questions — What are our goals for a 5.0.0 release? When do we
> think we should target its release?  I think we should address and gain
> consensus on these issues now rather than allow circumstances to answer
> them for us.
>
> Since I joined the community (back in the 4.1.0 days), 5.0.0 was a
> mythical, someday release when CloudStack would have a perfect
> architecture, build process, etc. -- a unicorn jumping a rainbow.  I
> realize that I have fallen into the trap of seeing 5.0.0 as some endpoint
> of perfection rather than an important milestone in the on-going
> improvement and evolution of the project.  Thinking it about is the former
> rather than the later, I realize that we have a legacy cruft that we need
> to discard in order to move forward and architectural design improvements
> that we must implement to address emerging infrastructure requirements.  I
> think we would be wise to separate these two objectives into a 5.0.0
> release (cruft removal/breaking refactorings) and 6.0.0 (backwards
> incompatible architectural redesign).  Not only do I see this approach as a
> risk mitigation, but also as a way to deliver improvements to users and
> developers as quickly as possible.
>
> For 5.0.0, my thought is that we would target the following high-level
> objectives:
>
> * Drop Java7 and adopt Java8 runtime and language features
> * Drop support for any hypervisor versions no longer supported by their
> vendors or communities
> * Drop any plugins which are no longer maintained or for which the
> community has no means to test
> * Drop support for any distributions no longer supported by their vendors
> or communities
> * Define an official support matrix for the project
> * Adopt a formal policy for sunsetting support of components based on the
> end-of-life dates set by their vendors or communities
> * Refactoring/cleanup of various APIs
> * Embedded Jetty/uberjar/unified YAML file configuration
>
> While I am sure there are more clean up items, the focus of the release
> would be to discard pieces that are in the way on further improvement.
>
> 6.0.0 would be released within 9-12 months of 5.0.0 — giving the community
> time to build atop 5.0.0 to redesign/improve the architecture of the system.
>
> I would like to see 5.0.0 released by the end of 2016 or at the beginning
> of 2017.  Based on the release plan I previously proposed, we would have
> the following releases remaining in 2016 and in early 2017:
>
> * 4.10 releasing on or about 28 August 2016
> * 4.11 releasing on or about 23 October 2016
> * 4.12 releasing on or about 18 December 2016
> * 4.13 release on or about 5 February 2017
>
> 4.12 seems to be the sweet spot in the schedule to cut the 5.0.0 release
> described above.  It would give us sometime to plan and gain consensus
> around the changes in both the user and dev communities.  It would also
> allow the second LTS release to be based on 5.0.0 — allowing both release
> cycles to take advantage of the reduced support requirements and Java8
> language features. Based on this proposal, the releases above would change
> to the following:
>
> * 4.10 releasing on or about 28 August 2016
> * 4.11 releasing on or about 23 October 2016
> * 5.0.0 releasing on or about 18 December 2016
> * 5.1.0 release on or about 5 February 2017
>
> 6.0.0 would be targeted for release in 4Q2017 — providing 9-12 months to
> design and implement architectural improvements.
>
> Thoughts?  Other paths to 5.0.0 and beyond?
> -John
> john.burwell@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
>
>
>


-- 
Daan

Re: [DISCUSS] 5.0.0 and 6.0.0

[John Burwell <jo...@shapeblue.com>]

Wido,

Please see my responses in-line below.

Thanks,
-John

> 
john.burwell@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue


On Jun 15, 2016, at 3:54 AM, Wido den Hollander <wi...@widodh.nl> wrote:
> 
> You really like typing long e-mails! :)

Not particularly, no.  However, this subject is hard to make small. :(

> 
>> Op 15 juni 2016 om 2:39 schreef John Burwell <jo...@shapeblue.com>:
>> 
>> 
>> All,
>> 
>> We have been discussing whether or not the next release would introduce the need to increment the major revision number from 4 to 5 (i.e. become 5.0.0).  While I think we are very close to the time to have a 5.0.0 release, I don’t think the next release will introduce any backwards compatible changes that necessitate.  However, Wido has brought two important questions — What are our goals for a 5.0.0 release? When do we think we should target its release?  I think we should address and gain consensus on these issues now rather than allow circumstances to answer them for us.
>> 
>> Since I joined the community (back in the 4.1.0 days), 5.0.0 was a mythical, someday release when CloudStack would have a perfect architecture, build process, etc. -- a unicorn jumping a rainbow.  I realize that I have fallen into the trap of seeing 5.0.0 as some endpoint of perfection rather than an important milestone in the on-going improvement and evolution of the project.  Thinking it about is the former rather than the later, I realize that we have a legacy cruft that we need to discard in order to move forward and architectural design improvements that we must implement to address emerging infrastructure requirements.  I think we would be wise to separate these two objectives into a 5.0.0 release (cruft removal/breaking refactorings) and 6.0.0 (backwards incompatible architectural redesign).  Not only do I see this approach as a risk mitigation, but also as a way to deliver improvements to users and developers as quickly as possible.
>> 
>> For 5.0.0, my thought is that we would target the following high-level objectives:
>> 
>> * Drop Java7 and adopt Java8 runtime and language features
>> * Drop support for any hypervisor versions no longer supported by their vendors or communities
>> * Drop any plugins which are no longer maintained or for which the community has no means to test
>> * Drop support for any distributions no longer supported by their vendors or communities
> 
> +1 to these points above.
> 
>> * Define an official support matrix for the project
>> * Adopt a formal policy for sunsetting support of components based on the end-of-life dates set by their vendors or communities
>> * Refactoring/cleanup of various APIs
>> * Embedded Jetty/uberjar/unified YAML file configuration
>> 
> 
> Not completely sure about a official support matrix, but I get the point.

What are your concerns?

> 
>> While I am sure there are more clean up items, the focus of the release would be to discard pieces that are in the way on further improvement.
>> 
>> 6.0.0 would be released within 9-12 months of 5.0.0 — giving the community time to build atop 5.0.0 to redesign/improve the architecture of the system.
>> 
>> I would like to see 5.0.0 released by the end of 2016 or at the beginning of 2017.  Based on the release plan I previously proposed, we would have the following releases remaining in 2016 and in early 2017: 
>> 
>> * 4.10 releasing on or about 28 August 2016
>> * 4.11 releasing on or about 23 October 2016
>> * 4.12 releasing on or about 18 December 2016 
>> * 4.13 release on or about 5 February 2017
>> 
>> 4.12 seems to be the sweet spot in the schedule to cut the 5.0.0 release described above.  It would give us sometime to plan and gain consensus around the changes in both the user and dev communities.  It would also allow the second LTS release to be based on 5.0.0 — allowing both release cycles to take advantage of the reduced support requirements and Java8 language features. Based on this proposal, the releases above would change to the following:
>> 
>> * 4.10 releasing on or about 28 August 2016
>> * 4.11 releasing on or about 23 October 2016
>> * 5.0.0 releasing on or about 18 December 2016 
>> * 5.1.0 release on or about 5 February 2017
>> 
> 
> My question is mainly who is going to support all versions and maintain them. Developers like to work on the newest stuff, so we get back to the LTS version. Person A fixes something in 5.0 and doesn't want/like to backport it to 4.X, what happens?
> 
> I'm all in favor of a 5.0 release, but we get back to the previously discussed topics around a LTS and the different views on that.

The release cycle I have proposed states that the only regular releases maintained are the current release and the current release - 1.  Therefore, when 5.0.0 is released, only the 5.0.0, 4.11, and LTS-4.9.0 branches will be maintained.  When 5.1.0 is released, the 5.1.0, 5.0.0, LTS-4.9.0, and LTS-5.0.0 (1 January 2017 would trigger another LTS release) branches would be supported.

> 
>> 6.0.0 would be targeted for release in 4Q2017 — providing 9-12 months to design and implement architectural improvements.
>> 
> 
> I think that 6.0 is to close, 9 months is not a lot of time for us at the moment.
> 

9 months may be too soon.  My thinking is that the best path of architectural improvement and significant functional improvements is a series of major releases rather than one large, high risk endeavor.  By placing specific timeframes and objectives around those releases, my hope is that we can better focus on smaller set of goals.  Do you think that a reasonable approach to improvement?

>> Thoughts?  Other paths to 5.0.0 and beyond?
>> -John
>> john.burwell@shapeblue.com 
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
>> @shapeblue

Re: [DISCUSS] 5.0.0 and 6.0.0

[Wido den Hollander <wi...@widodh.nl>]

You really like typing long e-mails! :)

> Op 15 juni 2016 om 2:39 schreef John Burwell <jo...@shapeblue.com>:
> 
> 
> All,
> 
> We have been discussing whether or not the next release would introduce the need to increment the major revision number from 4 to 5 (i.e. become 5.0.0).  While I think we are very close to the time to have a 5.0.0 release, I don’t think the next release will introduce any backwards compatible changes that necessitate.  However, Wido has brought two important questions — What are our goals for a 5.0.0 release? When do we think we should target its release?  I think we should address and gain consensus on these issues now rather than allow circumstances to answer them for us.
> 
> Since I joined the community (back in the 4.1.0 days), 5.0.0 was a mythical, someday release when CloudStack would have a perfect architecture, build process, etc. -- a unicorn jumping a rainbow.  I realize that I have fallen into the trap of seeing 5.0.0 as some endpoint of perfection rather than an important milestone in the on-going improvement and evolution of the project.  Thinking it about is the former rather than the later, I realize that we have a legacy cruft that we need to discard in order to move forward and architectural design improvements that we must implement to address emerging infrastructure requirements.  I think we would be wise to separate these two objectives into a 5.0.0 release (cruft removal/breaking refactorings) and 6.0.0 (backwards incompatible architectural redesign).  Not only do I see this approach as a risk mitigation, but also as a way to deliver improvements to users and developers as quickly as possible.
> 
> For 5.0.0, my thought is that we would target the following high-level objectives:
> 
> * Drop Java7 and adopt Java8 runtime and language features
> * Drop support for any hypervisor versions no longer supported by their vendors or communities
> * Drop any plugins which are no longer maintained or for which the community has no means to test
> * Drop support for any distributions no longer supported by their vendors or communities

+1 to these points above.

> * Define an official support matrix for the project
> * Adopt a formal policy for sunsetting support of components based on the end-of-life dates set by their vendors or communities
> * Refactoring/cleanup of various APIs
> * Embedded Jetty/uberjar/unified YAML file configuration
> 

Not completely sure about a official support matrix, but I get the point.

> While I am sure there are more clean up items, the focus of the release would be to discard pieces that are in the way on further improvement.
> 
> 6.0.0 would be released within 9-12 months of 5.0.0 — giving the community time to build atop 5.0.0 to redesign/improve the architecture of the system.
> 
> I would like to see 5.0.0 released by the end of 2016 or at the beginning of 2017.  Based on the release plan I previously proposed, we would have the following releases remaining in 2016 and in early 2017: 
> 
> * 4.10 releasing on or about 28 August 2016
> * 4.11 releasing on or about 23 October 2016
> * 4.12 releasing on or about 18 December 2016 
> * 4.13 release on or about 5 February 2017
> 
> 4.12 seems to be the sweet spot in the schedule to cut the 5.0.0 release described above.  It would give us sometime to plan and gain consensus around the changes in both the user and dev communities.  It would also allow the second LTS release to be based on 5.0.0 — allowing both release cycles to take advantage of the reduced support requirements and Java8 language features. Based on this proposal, the releases above would change to the following:
> 
> * 4.10 releasing on or about 28 August 2016
> * 4.11 releasing on or about 23 October 2016
> * 5.0.0 releasing on or about 18 December 2016 
> * 5.1.0 release on or about 5 February 2017
> 

My question is mainly who is going to support all versions and maintain them. Developers like to work on the newest stuff, so we get back to the LTS version. Person A fixes something in 5.0 and doesn't want/like to backport it to 4.X, what happens?

I'm all in favor of a 5.0 release, but we get back to the previously discussed topics around a LTS and the different views on that.

> 6.0.0 would be targeted for release in 4Q2017 — providing 9-12 months to design and implement architectural improvements.
> 

I think that 6.0 is to close, 9 months is not a lot of time for us at the moment.

> Thoughts?  Other paths to 5.0.0 and beyond?
> -John
> john.burwell@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
> 
>