On Mon, Aug 12, 2013 at 5:40 PM, Leif Hedstrom <zwoop@apache.org> wrote:
On Aug 12, 2013, at 5:10 PM, Igor Galić <i.galic@brainsware.org> wrote:

>
>
> This was exactly my problem at first. Leif was going with his proposal in one big zwoop from odd/even (-dev/stable) major.minor.patch releases to *just* major.minor releases (he's fixed that bit in the wiki by now)
>

Yes, I restored the major.minor.micro version concept. Sorry for obfuscating the issue unnecessarily. The updated proposals are still on

        https://cwiki.apache.org/confluence/display/TS/New+Release+Processes


>From what I can gather, the issue of contention is how to deal with incompatible changes. We're all in violent agreement that our long standing rule of not breaking compatibility within stable releases through the year is a given (e.g. 3.2.0 to v3.2.1 should always be safe).

Cheers,

-- Leif


I talked with Leif about this in person and I may be coming around to the idea.

The versioning would follow http://semver.org/. The PATCH version would essentially be used to do the version burn on a bad release vote and also for the LTS versions before the next MAJOR release. The LTS release (which is a new wrinkle Leif mentioned and I added to the wiki) would be something the more conservative amongst us. Those who chose to run LTS could test the other releases as if they were new feature dev releases leading up to the next LTS release. The more adventurous would run the MINOR updates as they came out quarterly. It's kinda like the best of both worlds in a way.

We just need to make sure to keep Alan committing on the incompatible-next-major-release branch. :)