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. -- Daniel Ruggeri
