git.net

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

Re: A proposal...



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