On April 24, 2018 6:53:52 AM CDT, Ruediger Pluem <rpl...@apache.org> wrote: > > >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
Yes, exactly correct. We have three "contracts" to keep that I think aligns very well with the following semver "contracts": Major => API/ABI compatibility for modules Minor => Feature and directives Patch => Functional and configuration syntax guarantees Demonstrating by way of a few examples: If we add a directive but do not change exported structure, that would result in a minor bump since the directive is part of the feature set that would necessitate a config change to use (not forward compatible). If we were to fix a security bug that does not impact running configs, that would be a patch bump since a config that works today must work tomorrow for the same maj.min. If we were to change default behavior, we would bump minor. This is because although the change doesn't break existing explicit configs of the directive, it would modify behavior due to implicit defaults => a visible change in functionality. Introducing H2 would have been a minor bump because it adds both new directives and new functionality. The switch from experimental to GA for H2 would have been a minor bump, not because of functional changes, but because of a change in our "contract" to users of code readiness. Refactoring exported core structures for better H2 support would be a major bump due to potential ABI breakage. A bug fix that requires API changes and adds directives would still be a major bump. Experiments for major changes would be done in a testing branch and merged to trunk as the next major. A minor bump (feature/functional/etc) would be cut from current trunk while a patch bump is made from the maj/minor it fixes (I haven't yet worked out what this proposal would look like in svn) In all cases, the changelog would clearly state the changes and we would ship what we consider to be the best default config. Ideally, we would also point the changelog entry to the SVN patches which implement the change so downstream has an easier time picking and choosing what they want. -- Daniel Ruggeri
