You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by John Burwell <jo...@shapeblue.com> on 2016/08/02 22:37:12 UTC
Re: [PROPOSAL] Early LTS Initial Release
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.burwell@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 <ra...@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.burwell@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
> <wido@widodh.nl ( wido@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.burwell@shapeblue.com ( john.burwell@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.burwell@shapeblue.com (
> john.burwell@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.burwell@shapeblue.com ( john.burwell@shapeblue.com
> ) www.shapeblue.com ( http://www.shapeblue.com )53 Chandos Place,
> Covent Garden, London VA WC2N 4HSUK@shapeblue
Re: [PROPOSAL] Early LTS Initial Release
Posted by Pierre-Luc Dion <pd...@cloudops.com>.
To me, if we would like to offer LTS, we need to fix following core issues:
- how database version is handle, right now database structure is mixed
with upgrade*.sql files and some java code
- better test upgrade path, I'm not sure we test them properly :-S
I have to admit I'm not fan of LTS release and would probably be -1, on
this for the following reasons:
Over the last year of so we start bumping old branch sub-release to back
port bugfixes, the idea is not bad, but we are now facing issues that
Upgrade paths are broken because older branch minor releases can be more
recent than latest main release as result as database consistency. last
example: 4.8.1 will be release after 4.9.0
A problematic issue that we are experiencing is the database structure, we
currently have a scenario in our infra where a fresh installation of 4.7.2
does not have the same `configuration` table content as an older system
that have that path: 4.4.0 -> 4.4.4 -> 4.7.0 -> 4.7.2
I blame our database versioning method, and the fact that we are changing
upgrade_*.sql files between releases. The reality is that once release
package are voted,
we should never change update*.sql files except for the next coming version
that as not been released yet. Rohit discussed about solution about this in
the past, we should review that.
Another issue we are seeing, that our personal experience at keep using an
old branch, is the complexity of submitting bug fixes that require 2 code
fixes if the main code diverge too much, back porting bug fixes or new
features is not trivial sometime because the code base change too much
between versions. This is not really inviting to submit bug fixes.
So now regression tests are event more complicated because a bug can be
fixed in an older branch but not in master due to code refactor, or
missing PR or merge.
Also, keeping users in previous branch prevent them to use latest
hypervisors releases (XenServer 7.0) and latest Guest OSes (ex: Ubuntu
16.04).
After running CloudStack for few years now, I found that remaining on an
old branch/release is a medium term dead end, because you end up with
inability to upgrade or use latest hypervisors and new guest OSes, upgrade
path is much more complex and involve much more efforts than upgrading
often as Shubberg proposed in the past. We have the capability to upgrade
our software as oppose to similar projects, so we should leverage this.
Last thing, I found the propose versioning is too complicated, why adding
5th and 6th digit, shouldn't we start bumping up 4.x.x to 5.x.x instead?
I don't want to block any initiative going that path, LTS, but I'm a bit
concerned in our current state and upgrade paths.
Regards,
Pierre-Luc
On Wed, Aug 3, 2016 at 2:33 AM, Rajani Karuturi <ra...@apache.org> wrote:
> 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.burwell@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.burwell@shapeblue.com
> ( john.burwell@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 <rajani@apache.org (
> rajani@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.burwell@shapeblue.com (
> john.burwell@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<wido@widodh.nl ( wido@widodh.nl ) ( wido@widodh.nl (
> wido@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.burwell@shapeblue.com ( john.burwell@shapeblue.com
> ) ( john.burwell@shapeblue.com ( john.burwell@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.burwell@shapeblue.com (
> -Johnjohn.burwell@shapeblue.com ) (john.burwell@shapeblue.com (
> john.burwell@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.burwell@shapeblue.com ( john.burwell@shapeblue.com
> ) ( john.burwell@shapeblue.com ( john.burwell@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
Re: [PROPOSAL] Early LTS Initial Release
Posted by Rajani Karuturi <ra...@apache.org>.
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.burwell@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.burwell@shapeblue.com ( john.burwell@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 <rajani@apache.org (
rajani@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.burwell@shapeblue.com (
john.burwell@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<wido@widodh.nl ( wido@widodh.nl ) ( wido@widodh.nl (
wido@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.burwell@shapeblue.com ( john.burwell@shapeblue.com
) ( john.burwell@shapeblue.com ( john.burwell@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.burwell@shapeblue.com (
-Johnjohn.burwell@shapeblue.com ) (john.burwell@shapeblue.com (
john.burwell@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.burwell@shapeblue.com ( john.burwell@shapeblue.com
) ( john.burwell@shapeblue.com ( john.burwell@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
Re: [PROPOSAL] Early LTS Initial Release
Posted by Rajani Karuturi <ra...@apache.org>.
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.burwell@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.burwell@shapeblue.com ( john.burwell@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 <rajani@apache.org (
rajani@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.burwell@shapeblue.com (
john.burwell@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<wido@widodh.nl ( wido@widodh.nl ) ( wido@widodh.nl (
wido@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.burwell@shapeblue.com ( john.burwell@shapeblue.com
) ( john.burwell@shapeblue.com ( john.burwell@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.burwell@shapeblue.com (
-Johnjohn.burwell@shapeblue.com ) (john.burwell@shapeblue.com (
john.burwell@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.burwell@shapeblue.com ( john.burwell@shapeblue.com
) ( john.burwell@shapeblue.com ( john.burwell@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