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.

And for the more complex modules like mod_proxy, mod_ssl and the event MPM, some of the hickups might have been hard to detect with the test framework. That's why I think having a more stable branch 2.4 with less feature backports and another branch that evolves faster would give downstreams a choice.

Regards,

Rainer

Reply via email to