The idea of maintaing the release branch longer can be discussed.
But, I am -1 for separate branches and separate release trains.
Maintaing the upgrade paths would be a big overhead.
We are not doing regular releases on the main release branches.
Rohit did a great job for 4.5(though it was backporting and not
forward merging at that time). Beyond that, we are not doing
regular releases. If we do regular updates on the release
branches, users who wish to take a release once in 6 months can
do so even now. It will just be current+6 release (assuming we do
regular minor releases every month)
~ Rajanihttp://cloudplatform.accelerite.com/
On August 3, 2016 at 4:07 AM, John Burwell
(john.burw...@shapeblue.com) wrote: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 (
http://markmail.org/thread/zh43rc6ahs4te46l ) 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
On Aug 2, 2016, at 3:57 AM, Rajani Karuturi <raj...@apache.org (
raj...@apache.org )> wrote:
We already maintain the release branches and do
regularreleases(of the past two releases) on them. What are we
achievingthrough 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 (
john.burw...@shapeblue.com )) wrote:Wido,
As proposed, LTS will be a branch of 4.9.0 with a six (6)
weekperiod of additional testing (i.e. soak/endurance,
scalability,and more extensive plugin testing). Therefore, LTS
releases willbe named <base release>_<LTS revision> meaning that
the first LTSrelease would be 4.9.0.0_1.0. The original
motivation for thisapproach was that the regular release cycle
performed testing fora week which was not enough time to execute
long running tests(e.g. the entire test suite requires roughly 4
days to run, agood endurance/soak test should run for 5-7
days,etc). Additionally, there was concern that LTS would impede
thevelocity of the regular release cycle. By decoupling
theregular and LTS release branches, there would be no
opportunityfor LTS constraints to impede velocity of the regular
releasecycle.
Since my original proposal, a number of aspects about the
releasecycle have changed. I am open to adjust LTS to simply be
anextension of the support period on the 4.9.0.0release.
Personally, I think the risk of the LTS cycle impedingregular
releases is very low. I also think it would be moreconsistent
with the way we have managed long running releases inthe past. We
would still perform the additional test we plannedfor LTS, but it
would on the 4.9 release branch rather than aseparate LTS branch.
Are there any objections to this change to the way LTS
branchesare managed and releases named? For now, I will leave the
LTSreleases in the schedule as defined in the originalproposal.
If/when we gain consensus on this change, I willadjust the
schedule.
Thanks,-John________________________________From: Wido den
Hollander<w...@widodh.nl ( w...@widodh.nl ) ( w...@widodh.nl (
w...@widodh.nl ) )>Sent: Friday, July 15, 20164:15:36
AMTo: dev@cloudstack.apache.org ( dev@cloudstack.apache.org
) (dev@cloudstack.apache.org ( dev@cloudstack.apache.org ) );
John BurwellSubject: Re: [PROPOSAL]Early LTS Initial ReleaseOp 13
juli 2016 om 18:25 schreef John
Burwell<john.burw...@shapeblue.com ( john.burw...@shapeblue.com
) ( john.burw...@shapeblue.com ( john.burw...@shapeblue.com ) )>:
All,Since LTS introduces a new release stream, I would like
topropose that we cut the first LTS quickly to verify that
variousaspects of the release cycle and version number
dependentcomponents will work properly with the new release
namingscheme. It will also allow us to flesh out distribution
issuessuch as download locations (e.g. for system VMs) and
publishingLTS documentation alongside regular releases. My
thinking isthat we would push an RC for this release within a
week of the4.9.0.0 release. If this additional release is
acceptable, Iwill update the release calendar to reflect the
followingchanges:* LTS 4.9.0.0_1.0* Development/Testing: 1 week
after 4.9.0.0release* RC Voting: 2 weeks after 4.9.0.0 release*
LTS4.9.0.0_2.0* Development/Testing: From 3 to 9 weeks of
the4.9.0.0 release* RC Voting: 10th week after the 4.9.0 releaseI
amfine with 4.9.0 as a LTS.But why a new vote for 4.9.0.0 as a
LTS? Isn't that a bitredundant?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 for4.9.0.0 to complete
voting.Thanks,-johnjohn.burw...@shapeblue.com (
-johnjohn.burw...@shapeblue.com ) (john.burw...@shapeblue.com (
john.burw...@shapeblue.com
))www.shapeblue.com<http://www.shapeblue.com (
http://www.shapeblue.com<http://www.shapeblue.com ) (
http://www.shapeblue.com<http://www.shapeblue.com (
http://www.shapeblue.com<http://www.shapeblue.com ) )>53
ChandosPlace, Covent Garden, London VA WC2N 4HSUK@shapeblue
john.burw...@shapeblue.com ( john.burw...@shapeblue.com
) ( john.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
