Wido,
As proposed, LTS will be a branch of 4.9.0 with a six (6) week period of additional testing (i.e. soak/endurance, scalability, and more extensive plugin testing). Therefore, LTS releases will be named <base release>_<LTS revision> meaning that the first LTS release would be 4.9.0.0_1.0. The original motivation for this approach was that the regular release cycle performed testing for a week which was not enough time to execute long running tests (e.g. the entire test suite requires roughly 4 days to run, a good endurance/soak test should run for 5-7 days, etc). Additionally, there was concern that LTS would impede the velocity of the regular release cycle. By decoupling the regular and LTS release branches, there would be no opportunity for LTS constraints to impede velocity of the regular release cycle. Since my original proposal, a number of aspects about the release cycle have changed. I am open to adjust LTS to simply be an extension of the support period on the 4.9.0.0 release. Personally, I think the risk of the LTS cycle impeding regular releases is very low. I also think it would be more consistent with the way we have managed long running releases in the past. We would still perform the additional test we planned for LTS, but it would on the 4.9 release branch rather than a separate LTS branch. Are there any objections to this change to the way LTS branches are managed and releases named? For now, I will leave the LTS releases in the schedule as defined in the original proposal. If/when we gain consensus on this change, I will adjust the schedule. Thanks, -John ________________________________ From: Wido den Hollander <w...@widodh.nl> Sent: Friday, July 15, 2016 4:15:36 AM To: dev@cloudstack.apache.org; John Burwell Subject: Re: [PROPOSAL] Early LTS Initial Release > Op 13 juli 2016 om 18:25 schreef John Burwell <john.burw...@shapeblue.com>: > > > All, > > Since LTS introduces a new release stream, I would like to propose that we > cut the first LTS quickly to verify that various aspects of the release cycle > and version number dependent components will work properly with the new > release naming scheme. It will also allow us to flesh out distribution > issues such as download locations (e.g. for system VMs) and publishing LTS > documentation alongside regular releases. My thinking is that we would push > an RC for this release within a week of the 4.9.0.0 release. If this > additional release is acceptable, I will update the release calendar to > reflect the following changes: > > * LTS 4.9.0.0_1.0 > * Development/Testing: 1 week after 4.9.0.0 release > * RC Voting: 2 weeks after 4.9.0.0 release > * LTS 4.9.0.0_2.0 > * Development/Testing: From 3 to 9 weeks of the 4.9.0.0 release > * RC Voting: 10th week after the 4.9.0 release > I am fine with 4.9.0 as a LTS. But why a new vote for 4.9.0.0 as a LTS? Isn't that a bit redundant? When we say 4.9.0 is good, what doesn't make it good for a LTS? Wido > I apologize for the relative dates — we are still waiting for 4.9.0.0 to > complete voting. > > Thanks, > -John > john.burw...@shapeblue.com > www.shapeblue.com<http://www.shapeblue.com> > 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK > @shapeblue > > > john.burw...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK @shapeblue
