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 <[email protected]> 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 > [email protected] > www.shapeblue.com > 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK > @shapeblue > > > -- Daan
