On 04/24/2018 01:50 PM, Rainer Jung wrote: > Am 24.04.2018 um 13:19 schrieb Daniel Ruggeri: >> >> >> On April 24, 2018 1:38:26 AM CDT, "Plüm, Rüdiger, Vodafone Group" >> <ruediger.pl...@vodafone.com> wrote: >>> >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: Rainer Jung <rainer.j...@kippdata.de> >>>> Gesendet: Montag, 23. April 2018 16:47 >>>> An: dev@httpd.apache.org >>>> Betreff: Re: A proposal... >>>> >>>> Am 23.04.2018 um 16:00 schrieb Jim Jagielski: >>>>> It seems that, IMO, if there was not so much concern about >>>> "regressions" in releases, this whole revisit-versioning debate would >>>> not have come up. This implies, to me at least, that the root cause >>> (as >>>> I've said before) appears to be one related to QA and testing more >>> than >>>> anything. Unless we address this, then nothing else really matters. >>>>> >>>>> We have a test framework. The questions are: >>>>> >>>>> 1. Are we using it? >>>>> 2. Are we using it sufficiently well? >>>>> 3. If not, what can we do to improve that? >>>>> 4. Can we supplement/replace it w/ other frameworks? >>>>> >>>>> It does seem to me that each time we patch something, there should >>> be >>>> a test added or extended which covers that bug. We have gotten lax in >>>> that. Same for features. And the more substantial the change (ie, the >>>> more core code it touches, or the more it refactors something), the >>> more >>>> we should envision what tests can be in place which ensure nothing >>>> breaks. >>>>> >>>>> In other words: nothing backported unless it also involves some >>>> changes to the Perl test framework or some pretty convincing reasons >>> why >>>> it's not required. >>>> >>>> I agree with the importance of the test framework, but would also >>> like >>>> to mention that getting additional test feedback from the community >>>> seems also important. That's why IMHO the RC style of releasing could >>> be >>>> helpful by attracting more test effort before a release. >>> >>> I think RC style releasing could help. Another thought that came to my >>> mind that >>> I haven't worked out how we could implement this is the following: >>> >>> Do "double releases". Taking the current state we would do: >>> >>> Release 2.4.34 and 2.4.35 at the same time. 2.4.34 only contains bug >>> fixes / security fixes. >>> 2.4.35 additional features / improvements on top of 2.4.34 as we do so >>> far. >>> >>> The next "double release" would be 2.4.36 / 2.4.37. 2.4.36 only >>> contains bug fixes / security fixes >>> on top of 2.4.35, 2.4.37 additional features / improvements on top of >>> 2.4.36. >>> So 2.4.36 would contain the additional features / improvements we had >>> in 2.4.35 as well, but they >>> have been in the "wild" for some time and the issues should have been >>> identified and fixed as part >>> of 2.4.36. >>> Users would then have a choice what to take. >>> >>> Regards >>> >>> Rüdiger >> >> Interesting idea. This idea seems to be converging on semver-like principles >> where the double release would look like: >> 2.12.4 => 2.12.3 + fixes >> 2.13.0 => 2.12.4 + features >> ... which I like as a direction. However, I think distinguishing between >> patch/feature releases in the patch number >> alone would be confusing to the user base. > > ... although at least in the Java world that is what happens there since a > few years. For example Java 1.8.0_171 > includes security fixes and critical patches, 1.8.0_172 released at the same > day includes additional features. Or as > Oracle phrases it: "Java SE 8u171 includes important bug fixes. Oracle > strongly recommends that all Java SE 8 users > upgrade to this release. Java SE 8u172 is a patch-set update, including all > of 8u171 plus additional bug fixes > (described in the release notes).".
Damn it. You found the source of my idea :-) > > Unfortunately it seems they have given up the idea starting with Java 9. So > pointing to the Java 8 situation is not that > convincing ... IMHO the whole Java versioning after 8 is not very appealing to me. But this is just following the general new version strategy of Oracle which I regard as confusing with respect to support lifecycles. Regards Rüdiger
