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

Re: A proposal...

On 04/24/2018 01:50 PM, Rainer Jung wrote:
> 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).".

Damn it. You found the source of my idea :-)

> Unfortunately it seems they have given up the idea starting with Java 9. So pointing to the Java 8 situation is not that
> convincing ...

IMHO the whole Java versioning after 8 is not very appealing to me. But this is just following the general new version
strategy of Oracle which I regard as confusing with respect to support lifecycles.