Rajani, As I mentioned in my previous email, the original motivation for a completely separate branch was based on objections by some community members that the longer, more conservative LTS release cycle would place a drag on the velocity of regular releases. Additionally, users interested in LTS releases voiced their desire to have fewer releases a year. Therefore, where the regular release cycle is scheduled to make major releases every 2 months and maintenance releases every month, the LTS cycle makes major releases every 6 months and maintenance releases less frequently (e.g. every 3 months). These longer cycles allow users with longer acceptance test/verification cycles to more easily keep up with upgrades. Completely separate branches and release cycles were proposed to serve both use cases (rapid, leading upgrades and more traditional maintenance cycles).
I am open to collapsing LTS into the regular maintenance releases (e.g. 4.9 simply becomes supported for 20 months instead of 4 months). Ultimately, I would like that decision to be based on user feedback since separate release branches/cycles have been previously discussed with no objections [1]. I have CC’ed users@ to solicit thoughts from our users on which approach would be preferred. Thanks, -John [1]: http://markmail.org/thread/zh43rc6ahs4te46l > john.burw...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK @shapeblue On Aug 2, 2016, at 3:57 AM, Rajani Karuturi <raj...@apache.org> wrote: > > 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
