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 Tue, 12 Jan 2016 19:04:55 GMT
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.


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.
>Sent from the Delta quadrant using Borg technology!
>----- 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 newer
>> 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
>>>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, it
>>>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.
>>>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 be
>>>> 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 the
>>>>> upgrade path."
>>>>> So 4.6.0, 4.6.1 and 4.6.2 can all be upgraded to 4.7.0 or the latest
>>>>> If a user absolutely needs a fix that breaks this, then it is their
>>>>> 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
>>>>> 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
>>>>> point or continue their private fork forever.
>>>>> There is nothing wrong to saying that "Bug xx is only fixed in version
>>>>> 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.
>>>>>>> can only upgrade to versions that are released _after_ the specific
>>>>>>> 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:
>>>>>>> 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
>>>>>> 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
>>>Artifact Software Inc
>>>skype: ronaldmwheeler
>>>phone: 866-970-2435, ext 102
View raw message