cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burwell <>
Subject Re: [PROPOSAL] Early LTS Initial Release
Date Tue, 02 Aug 2016 22:37:12 GMT

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.



53 Chandos Place, Covent Garden, London VA WC2N 4HSUK

On Aug 2, 2016, at 3:57 AM, Rajani Karuturi <> 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
> ~ Rajani
> On August 2, 2016 at 2:33 AM, John Burwell
> ( 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 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
> 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
> < ( )>Sent: Friday, July 15, 2016
> 4:15:36 AMTo: (
> ); John BurwellSubject: Re: [PROPOSAL]
> Early LTS Initial Release
> Op 13 juli 2016 om 18:25 schreef John Burwell
> < ( )>:
> 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
> release. If this additional release is acceptable, I
> will update the release calendar to reflect the following
> changes:
> * LTS* Development/Testing: 1 week after
> release* RC Voting: 2 weeks after release* LTS
>* Development/Testing: From 3 to 9 weeks of the
> 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 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
> to complete voting.
> Thanks, (
> )< (<
)>53 Chandos
> Place, Covent Garden, London VA WC2N 4HSUK@shapeblue
> (
> ) ( )53 Chandos Place,
> Covent Garden, London VA WC2N 4HSUK@shapeblue

View raw message