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

AW: A proposal...

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