> -----Ursprüngliche Nachricht----- > Von: William A Rowe Jr [mailto:wr...@rowe-clan.net] > Gesendet: Dienstag, 24. Oktober 2017 19:00 > An: httpd <firstname.lastname@example.org> > Betreff: [Proposal] 2.5.x -> 2.6.0/3.0.0 transition guidelines > > I'd like to propose the following, so we can decide on what course to > chart between here and there. > > Today we are at 2.5.0-dev, slated to become 2.5.0 non-GA release. > Through a series of non-GA releases, 2.5.x is eventually approved to > become the next 'evens' GA release. What we number that by default is > 2.6.0, or if the group decides the changes are significant enough, > 3.0.0. > > What I propose now is that we designate all 2.5.x releases as -alpha > *until the list decides the API (not ABI) changes are complete*. > That's the only process change. > > We track this through STATUS, with a vote to promote API-changing > proposals to SHOWSTOPPERs to -beta. So developers will be aware when > we declare -beta that we will no longer change the API for them, and > their modules must conform to the new API, barring any radical > discoveries that prevent us from shipping that API (which might then > return us to the -alpha phase.) > > E.g. we had a security@ discussion about changing the handling of URI > significantly so that the meaning of escaped vs. unescaped characters > is never obtuse. There are several proposals on that table (embargoed > at that time waiting for our HTTP protocol correctness patches to be > published.) Those need to come here to dev@. One of them will land in > STATUS, and will inevitably be upvoted to SHOWSTOPPER status; > 2.5.x-beta shouldn't happen, IMO, until some code and structure > changes to accomplish this has been accepted. > > Because it is CTR, we don't need STATUS for patch voting, but I do > think we want STATUS to identify what is the minimum changes needed to > declare the next API/ABI-breaking release complete and ready for > -beta. > > Thoughts?
The guidelines are fine with me and seem to make sense to get to an API stable next GA. It is good to have a list of 'To Do's' that needs to be done before next GA. That helps people looking for interesting and useful work to spend their time :-). Once it is decided that the API is stable I guess we need to branch in order to avoid restraining further progress on trunk by developers that want to change the API further in an incompatible way. This could still be a '2.5.x' branch that morphs into a 2.6.x or 3.0.x branch later. My personal itch and use of my regrettably very limited amount of time these days is on the current 2.4 and getting at least some of the features back into it (a little bit like Jim's approach). This has to do with my dayjob where it is much easier to upgrade to 2.4.next than to a new GA version. But I see merit in getting more track on moving forward with current trunk to something releasable. So go for the alpha tags and see if you get sufficient votes for it and what the feedback of the broader community is. If it is valuable: Great. If not or if it doesn't lift off no harm is done IMHO. Then the alpha release will just stop due to lack of interest in the community. Regards Rüdiger