> -----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,
> 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
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
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
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
releasable. So go for the alpha tags and see if you get sufficient votes for it
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
due to lack of interest in the community.