I am not sure that the world would end if the EOL was extended for a
particularly popular LTS release if the subsequent releases were not as
stable as some people liked or did not include sufficient new features
to motivate a lot of happy users to upgrade.
If the pace of enhancements is slow and there are a small number of bug
fixes requiring backporting, this could be manageable.
At the moment, would it be reasonable for a new installation to start
with the latest 4.9.x if the EOL was 2020 and the EOL of 4.10.x was 2021?
Perhaps for many people the risk of starting with .1 release of 4.10
today rather than a .3 release of 4.9 would outweigh the benefit of the
extra year of support. That analysis would gradually change as 4.10 gets
additional minor releases and 2020 gets closer.
One would hope that the number of critical enhancements and bug fixes
will reduce as the product becomes more mature.
In addition, as the functionality required by an increasing percentage
of users is incorporated into the product, the attractiveness of a new
release will be reduced. Users will want LTS to be extended for longer
periods since upgrading does not buy them very much and possibly nothing
at all in their particular use case as long as bugs are fixed.
This should be viewed as a sign of successful design and strong
implementation rather than a loss of momentum.
Ron
On 22/11/2017 8:44 PM, Ivan Kudryavtsev wrote:
Hi, all. Previous reply to wrong thread. Copy here.
According to Paul, everything looks ok, but I still feel the website
content is lacking of the information. My belief that index should clearly
state:
Current LTS 4.9 | updated 2017.11.12 (4.9.3) | EOL=2018.X.Y
Previous LTS 4.X | updated 2017.04.01 (4.X.12) | EOL=2017.X.Y
Current 4.10 | updated 2017.11.20 (4.10.1) | EOL=2018.05.Y
The same is for download page. The reason is that some people don't need
new, they need very proven. Other need supported and third group needs
features.
E.g. Right now we updated our proxmox nodes to latest stable and found
windows 8 is no longer works as expected. Previous stable - ok. We rolled
back. I mean that it could be a good way for a lot of users to see and
realize what options they have. Even now, we still have 4.3 in production
and happy.
Right now, new person just downloads 4.10 and gets a lot of regressions and
unstable code. You might have seen last day e-mail threads. Even templates
created from snapshots are broken in 4.10 and it is critical/blocker bug.
The user can meet the situation, that after a months when ssvm is reloaded
all users lost tons of templates.
22 нояб. 2017 г. 11:49 ПП пользователь "Will Stevens" <wstev...@cloudops.com>
написал:
Paul, I thought a 'big mouth' was a prerequisite for the RM position.
Isn't that the only reason I was the 4.9 RM? :P
*Will Stevens*
CTO
<https://goo.gl/NYZ8KK>
On Wed, Nov 22, 2017 at 11:39 AM, Paul Angus <paul.an...@shapeblue.com>
wrote:
HI All,
The current LTS cycle is based on having an LTS release twice a year (at
the time of design, ACS releases were coming out monthly).
So, twice a year (nominally, January and July) we take the then current
version of CloudStack, and declare that an LTS version, for which would we
would then backport fixes for a period of up to 2 years. Thereby giving
end users a version of CloudStack which would receive bug fixes for an
extended period.
This year however, the current version in January was the same as the
current version in July, therefore 4.9 became the 'July' LTS as well as
January LTS and therefore 4.9 will be supported until summer 2019 (hence
the 4.9.3 release)
I and a number of my colleagues remain committed to continue to support
'LTS' releases in this fashion (there just wasn't anything really to
'announce' in July), which may be why people think that nothing is
happening.
With 2 LTS releases a year (6 months apart), 'next LTS +6 months' would
only be 12 months from release. Which I think is really too short a
period
for the majority of enterprises. Although we haven't written it this way,
the current scheme gives a EOL of 'next LTS + 18 months'.
So, I'm in favour of leaving things as they are. The wiki page looks
like it needs updating to be clearer (I'm happy to do that)
But I DO think that we should start a new thread asking for a 4.11 RM
volunteer to get things going. (I'm guessing y'all don't what my big
mouth in that position).
Kind regards,
Paul Angus
paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
-----Original Message-----
From: Ivan Kudryavtsev [mailto:kudryavtsev...@bw-sw.com]
Sent: 21 November 2017 14:00
To: dev@cloudstack.apache.org
Subject: Re: CloudStack LTS EOL date?
Hello, it sounds very reasonable. The more lifecycle information the
better for adopters.
21 нояб. 2017 г. 8:56 ПП пользователь "Marc-Aurèle Brothier - Exoscale" <
ma...@exoscale.ch> написал:
It makes more sense to me too.
On Tue, 2017-11-21 at 12:04 +0100, Rene Moser wrote:
Hi all
The current LTS release is 4.9 which is EOL in June 2018 according
to https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
AFAIK there are no works planed for a new LTS. The release pace has
slown down (the high pace and leaving users behind fixes was the
reason for the LTS).
I am still pro LTS but in my opinion we should have defined the EOL
in relation of the successor LTS release date: "The EOL of the
current LTS is +6 months after the next LTS release."
Small example:
Current LTS 4.9
Next LTS 4.1x release on 01.04. --> LTS 4.9 is 01.10.
Does this make sense? Other suggestions?
Regards
René
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
