[rfc] six-month stable release cycles

[Russ Brown]

On Wednesday 29 July 2009 01:39:49 am Martin Pool wrote:
> A longer stable cycle has often been requested.  I think we should do
> it, now, along the lines of this document.   (It's in devnotes and
> also as a pdf for those who like it that way.)

I agree. My only question regards version numbering: unless I've misread 
something, you seem to be ignoring the middle part of the version number. i.e. 
2.1.0 etc.

I personally very fond of the postgres-style [1] of numbering. The last digit 
denotes a bugfix release, so 2.1.x has the same (intended) functionality 
regardless of the value of x. They guarantee that these releases don't change 
functionality unless required in order to fix a security bug.

The middle digit denotes general functionality changes: performance and 
feature enhancements.

The first digits is reserved for "big" releases: i.e. those that include 
considerable rewriting, large features change changes very visible to the 
user.

Mapping that to bzr, 2.0 clearly fits this already since it's a completely new 
format with considerable code changes around it. But the next release (barring 
bug fix releases) would probably end up being 2.1. You may want to reserve the 
major version number increases for format bumps, or maybe API compatibility 
breaks: that would be something to decide upon.

Just my 2c. :)

[1] http://it.toolbox.com/blogs/database-soup/guide-to-postgresql-version-
numbers-19177

-- 

Russ