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! www.nux.ro ----- Original Message ----- > From: "Remi Bergsma" <rberg...@schubergphilis.com> > To: dev@cloudstack.apache.org > 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" <rwhee...@artifact-software.com> 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, 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. >> >> >>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 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 <rwhee...@artifact-software.com >>>> 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 4.7.x >>>> 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 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 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. 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: rwhee...@artifact-software.com >>>> skype: ronaldmwheeler >>>> phone: 866-970-2435, ext 102 >>>> >>>> >>> >> >> >>-- >>Ron Wheeler >>President >>Artifact Software Inc >>email: rwhee...@artifact-software.com >>skype: ronaldmwheeler >>phone: 866-970-2435, ext 102
