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?

Reply via email to