On 04/24/2018 01:19 PM, Daniel Ruggeri wrote: > > > 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. >
And for 2.x we would stay API/ABI stable just like as we do to day with a stable release? The next API/ABI incompatible version would be 3.x in that scheme? Regards Rüdiger
