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?
