git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A proposal...


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.pluem@xxxxxxxxxxxx> wrote:


-----Ursprüngliche Nachricht-----
Von: Rainer Jung <rainer.jung@xxxxxxxxxxx>
Gesendet: Montag, 23. April 2018 16:47
An: dev@xxxxxxxxxxxxxxxx
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