We already maintain the release branches and do regular releases(of the past two releases) on them. What are we achieving through this LTS model? How is 4.9.1 different from 4.9.0.0_1.0?
~ Rajanihttp://cloudplatform.accelerite.com/ On August 2, 2016 at 2:33 AM, John Burwell (john.burw...@shapeblue.com) wrote: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 ( w...@widodh.nl )>Sent: Friday, July 15, 2016 4:15:36 AMTo: dev@cloudstack.apache.org ( dev@cloudstack.apache.org ); John BurwellSubject: Re: [PROPOSAL] Early LTS Initial Release Op 13 juli 2016 om 18:25 schreef John Burwell <john.burw...@shapeblue.com ( 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 releaseI 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? WidoI apologize for the relative dates — we are still waiting for 4.9.0.0 to complete voting. Thanks,-johnjohn.burw...@shapeblue.com ( john.burw...@shapeblue.com )www.shapeblue.com<http://www.shapeblue.com ( http://www.shapeblue.com<http://www.shapeblue.com )>53 Chandos Place, Covent Garden, London VA WC2N 4HSUK@shapeblue john.burw...@shapeblue.com ( john.burw...@shapeblue.com ) www.shapeblue.com ( http://www.shapeblue.com )53 Chandos Place, Covent Garden, London VA WC2N 4HSUK@shapeblue
