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 >
