You really like typing long e-mails! :) > Op 15 juni 2016 om 2:39 schreef John Burwell <john.burw...@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.burw...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK > @shapeblue > >
