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
