cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burwell <>
Subject Re: LTS release or not
Date Thu, 14 Jan 2016 07:21:19 GMT

It seems that there is general agreement on the following:

1. There are users that need periodic releases that only focus on stability to minimize change
and deployment risk (i.e. LTS releases)
2. There are users that need frequent releases that deliver new capabilities (i.e. monthly
3. These two release types are not mutually exclusive and can be developed in a complementary
4. Assuming community has the resources available, we would like to deliver both monthly and
LTS releases

For a sometime, ShapeBlue have been considering a proposal to supplement the monthly release
cycle with an LTS release cycle. We believe that offering both monthly and LTS releases will
make CloudStack more attractive to new users, as well as, addressing the requirements of all
current CloudStack users. I expect to publish an LTS proposal within the next day or so that
includes most, if not all, of the points discussed on this thread. Hopefully, we will quickly
gain consensus on an LTS release cycle, and begin doing the work necessary to deliver high
quality LTS releases.



John Burwell

d:      +44 (20) 3603 0542 | s: +1 (571) 403-2411 <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e: | t: <|%20t:>
    |      w:<>

a:      53 Chandos Place, Covent Garden London WC2N 4HS UK


Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India
LLP is a company incorporated in India and is operated under license from Shape Blue Ltd.
Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under
license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic
of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered
This email and any attachments to it may be confidential and are intended solely for the use
of the individual to whom it is addressed. Any views or opinions expressed are solely those
of the author and do not necessarily represent those of Shape Blue Ltd or related companies.
If you are not the intended recipient of this email, you must neither take any action based
upon its contents, nor copy or show it to anyone. Please contact the sender if you believe
you have received this email in error.

On Jan 12, 2016, at 2:43 PM, Nux! <> wrote:
> Remi,
> Yes, that, that's great then, thanks.
> Lucian
> --
> Sent from the Delta quadrant using Borg technology!
> Nux!
> ----- Original Message -----
>> From: "Remi Bergsma" <>
>> To:
>> Sent: Tuesday, 12 January, 2016 19:04:55
>> Subject: Re: LTS release or not
>> Hi Lucian,
>> Are you referring to the forward merging?
>> That has been scripted:
>> There may be conflicts at some point, but that also happens with cherry-picking.
>> If you mean something else I probably missed your point, sorry.
>> Regards,
>> Remi
>> On 12/01/16 17:17, "Nux!" <> wrote:
>>> Guys, I am not a coder to appreciate how sustainable this would be.
>>> Who around here with actual java skills thinks this is achievable in a
>>> reasonable way? Cause if it's not we're just wasting time.
>>> Lucian
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>> Nux!
>>> ----- Original Message -----
>>>> From: "Remi Bergsma" <>
>>>> To:
>>>> Sent: Tuesday, 12 January, 2016 15:36:52
>>>> Subject: Re: LTS release or not
>>>> Hi,
>>>> The method Daan describes can be done from 4.6 and on. It’s about merging
a PR
>>>> with a fix, and forward merging it. Not about actually releasing immediately.
>>>> If the bug has always been there, one would merge to 4.6, merge forward to
>>>> releases (and finally master) and then back port (aka cherry-pick) to 4.5.
>>>> Regards,
>>>> Remi
>>>> On 12/01/16 15:55, "Ron Wheeler" <> wrote:
>>>>> Depending on how far back the problem originated, this may not be
>>>>> practical.
>>>>> The code might have been massaged many times or code may have been
>>>>> written that depends on the buggy behaviour.
>>>>> If the bug "was always there" but no one had figured out the exploit,
>>>>> might not be possible to identify any particular commit at all.
>>>>> Would your solution trigger a whole bunch of new releases - 4.4.x,
>>>>> 4.5.y, 4.6.z, 4.7.1, etc. or would the fix just be applied to the branch
>>>>> and noted while we wait for enough to accumulate to trigger a new
>>>>> release? Who would want to work on 4.4.x release?
>>>>> The amount of testing required to support all that backporting would
>>>>> certainly deter people from fixing old bugs!
>>>>> No code is bug free so I am not sure how bad it is to say that a bug
>>>>> will only be fixed in the LTS and current release.
>>>>> System administrators can then decide if the bug is worth an update to
>>>>> the fixed version or should be fixed on the release that they currently
>>>>> run, causing a local fork that they will deal with during their next
>>>>> upgrade cycle.
>>>>> Ron
>>>>> On 12/01/2016 2:18 AM, Daan Hoogland wrote:
>>>>>> ok, one last €0,01: any bug should be fixed not on the branch but
on the
>>>>>> commit it was introduced in and thenn be merged forward. It can then
>>>>>> merged into any branch that contains the offending commit and there
is no
>>>>>> longer any difference between LTS or anything else. Am I speaking
>>>>>> Kardeshian? I am really surprised no one in this list sees source
code and
>>>>>> release management this way.
>>>>>> On Mon, Jan 11, 2016 at 5:34 PM, Ron Wheeler <
>>>>>>> wrote:
>>>>>>> There may have to be some rules about patches such as
>>>>>>> "You may not apply any bug fix to a minor release that will break
>>>>>>> upgrade path."
>>>>>>> So 4.6.0, 4.6.1 and 4.6.2 can all be upgraded to 4.7.0 or the
latest 4.7.x
>>>>>>> If a user absolutely needs a fix that breaks this, then it is
>>>>>>> problem to upgrade to 4.7.x rather than building a long-term
problem into a
>>>>>>> stable branch.
>>>>>>> At some point no one will be happy with the latest 4.6.x and
everyone will
>>>>>>> upgraded.
>>>>>>> Any user that applies the offending patch to 4.6.2 should know
that they
>>>>>>> have created their own misery and will have to work out the upgrade
at some
>>>>>>> point or continue their private fork forever.
>>>>>>> There is nothing wrong to saying that "Bug xx is only fixed in
>>>>>>> 4.8.0 and later".
>>>>>>> Even if version 4.6.5 came out a month after 4.8.0, bug xx is
not fixed.
>>>>>>> No piece of software is bug-free so we are really discussing
what happens
>>>>>>> once a bug is found and a fix is available.
>>>>>>> 4.6.5 will run exactly like it did before the bug was found.
>>>>>>> Bugs that will cause update issues will trigger a new major release.
>>>>>>> If the current supported releases are 4.6.2 and 4.7.1 then the
bug will
>>>>>>> cause a 4.8.0 to come into existence with an upgrade path that
goes from
>>>>>>> 4.6.2 to 4.7.0 (or 4.7.1 which should be the identical upgrade)
to 4.8.0
>>>>>>> My 2 cents!
>>>>>>> Ron
>>>>>>> On 11/01/2016 10:23 AM, Rene Moser wrote:
>>>>>>>> Hi Remi
>>>>>>>> On 01/11/2016 04:16 PM, Remi Bergsma wrote:
>>>>>>>>> Maintaining LTS is harder than it seems. For example
with upgrading. You
>>>>>>>>> can only upgrade to versions that are released _after_
the specific LTS
>>>>>>>>> version. This due to the way upgrades work. If you release
4.7.7 when we’re
>>>>>>>>> on say 4.10, you cannot upgrade to 4.8 or 4.9. The same
for 4.5: 4.5.4
>>>>>>>>> cannot upgrade to any 4.6, 4.7 or 4.8 because it simply
didn’t exist when
>>>>>>>>> these versions were released. (4.5.3 has been accounted
for so that does
>>>>>>>>> work this time). If you want to keep doing 4.5 releases
18 months from now,
>>>>>>>>> that’s going to be a real issue. Users probably won’t
understand and expect
>>>>>>>>> it to work. And yes, we will change the upgrading procedures
but it’s not
>>>>>>>>> there yet.
>>>>>>>> Out of curiosity. I thought about patch relases like this
scheme 4.5.2.x
>>>>>>>> for LTS. This would work right?
>>>>>>>> Regards
>>>>>>>> René
>>>>>>> --
>>>>>>> Ron Wheeler
>>>>>>> President
>>>>>>> Artifact Software Inc
>>>>>>> email:
>>>>>>> skype: ronaldmwheeler
>>>>>>> phone: 866-970-2435, ext 102
>>>>> --
>>>>> Ron Wheeler
>>>>> President
>>>>> Artifact Software Inc
>>>>> email:
>>>>> skype: ronaldmwheeler
>>>>> phone: 866-970-2435, ext 102

Find out more about ShapeBlue and our range of CloudStack related services:
IaaS Cloud Design & Build<> |
CSForge – rapid IaaS deployment framework<>
CloudStack Consulting<> | CloudStack Software
CloudStack Infrastructure Support<>
| CloudStack Bootcamp Training Courses<>

  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message