cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remi Bergsma <>
Subject Re: LTS release or not
Date Mon, 11 Jan 2016 15:16:17 GMT

IMHO we should pick 4.7 instead of 4.6 as it has newer features (like the Metrics UI and some
more stuff). Apart from that 4.7 has had more bug fixes. These could have been merged to 4.6,
but we didn’t always do that. Let’s make sure we keep doing that for 4.7, also when 4.8
is out. Apart from that 4.7.0 == 4.6.2. If one upgrade is easy, it’s 4.6.2 to 4.7.0 so let’s
not bother. Pick 4.7, it’s better. Trust me.

I also say, should we want to do something LTS-like, we pick a branch, aka '4.7’, rather
than a specific version like ‘4.7.1’ etc. Don’t see how we could LTS a single version.

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.

I do understand people want to make 4.5 LTS instead of a more recent version. Except for the
above, it’s doable. It’s a lot of extra work, but if people feel it’s worth it they
can of course do it. Rohit for example also maintained 4.3 for a long time. Pre-4.6 back porting
was the way to go, so you can continue to do that. From 4.6, the workflow is based on forward-merging,
as Daan explained so no cherry-picking there.

Generally speaking, I don’t like it when people have a strong opinion on something and they
don’t work on it themselves. So, as I probably won’t be working on LTS releases, I won’t
-1 it for this reason. I'm just trying to help understand what it’d be like.


On 11/01/16 14:47, "Sebastien Goasguen" <> wrote:

>> On Jan 11, 2016, at 2:41 PM, Nux! <> wrote:
>> Daan,
>> Ok, that sounds good, but at this point it's really up to the people writing actual
>> Wido has already voted against it and SBP guys don't seem too keen on it either.
>Exactly, we can say we want an LTS, but then we need a RM.
>and FWIW, I would think we want to LTS starting with 4.6.2.
>We need to make sure all upgrade to 4.6.2 work and start there.
>The reason being that subsequent upgrade and LTS maintenance should be much easier as
the upstream ( 4.7+) gets the benefit of the new workflow.
>> --
>> Sent from the Delta quadrant using Borg technology!
>> Nux!
>> ----- Original Message -----
>>> From: "Daan Hoogland" <>
>>> To: "dev" <>
>>> Sent: Monday, 11 January, 2016 13:36:06
>>> Subject: Re: LTS release or not
>>> Any version that is not a year old should be LTS in my view. We must as
>>> reviewers take care that fixes are merged on the oldest branch first and
>>> then merged forward along the line. To me this was the whole purpose of the
>>> changes we did to our release process. Are we abandonning this now to
>>> return to fixing on seperate branches and have the same fix in multiple
>>> commitishes? Excuse my Dutch: That sucks.
>>> On Mon, Jan 11, 2016 at 2:28 PM, Nux! <> wrote:
>>>> I think LTS is a good idea, but I am afraid we'd be spreading ourselves
>>>> too thin with maintaining that in addition to mainline.
>>>> The way I see it, one way to have this sorted is by means of commercial
>>>> offerings from companies such as ShapeBlue.
>>>> What lifetime are we talking rougly for an LTS release? 6 months, 12
>>>> months?
>>>> Lucian
>>>> --
>>>> Sent from the Delta quadrant using Borg technology!
>>>> Nux!
>>>> ----- Original Message -----
>>>>> From: "Daan Hoogland" <>
>>>>> To: "dev" <>
>>>>> Sent: Monday, 11 January, 2016 13:19:48
>>>>> Subject: Re: LTS release or not
>>>>> On Mon, Jan 11, 2016 at 7:58 AM, Rene Moser <>
>>>>>>>> * Fix must be important.
>>>>>>> Who defines what 'important' is?
>>>>>> "must be important" means we do not backport trivial things like
>>>>>> in docs and so forth, only important things. And I would say important
>>>>>> in a common sense. But it doesn't mean that all important fixes will
>>>>>> backportable, because they may not be necessary "obvious and small".
>>>>> ​if it is really important it should be fixed on the LTS first and
>>>>> merged to 'bleeding edge' if still applicable.
>>>>> ​
>>>>> ​Limitation of warranty: I really don't like this discussion as it
>>>> negates
>>>>> most of the hard weekend work I did over the last half year.​
>>>>> --
>>>>> Daan
>>> --
>>> Daan
View raw message