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).".
Unfortunately it seems they have given up the idea starting with Java 9.
So pointing to the Java 8 situation is not that convincing ...
Regards,
Rainer
