Re: A proposal...

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