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 > > -- Daan
