Re: Release Policy

[Richard Frith-Macdonald]

On 7 Nov 2007, at 20:22, Adam Fedor wrote:

> I though I understood the release policy (have written some of it :- 
> (  ), but now I'm confused again.
>
> For instance, for the base library, we currently have a stable  
> release (1.14.0) and an unstable release (1.15.0) which are identical.

I think they are not quite identical,  though we have had very, very  
few (if any) changes other than bugfixes since the last release ...

> I'm going to make another stable release 1.14.1 from the  
> stable-1_14_0 branch.  That part is easy.
>
> Now what about the unstable release?  Since we have an unstable  
> release 1.15.0, should the next unstable release be 1.15.1?

Sure.

>   That seems to be the point of the unstable release branch, but  
> the policy also states that any compatibility change requires us to  
> bump the minor version number, which means we have to make 1.16.0  
> release, so now I don't see the point of having an unstable release  
> branch.

Where we are talking about updating the minor version number we are  
talking about breaking source code backward compatibility so that old  
source will no longer work with the new release.  For this we need a  
minor version number change for the unstable releases (and we can't  
have a new release of a stable branch).  I don't think there are any  
such compatibility changes on trunk.

Within a stable branch we are concerned with both binary  
compatibility and api stability ... so (barring dependency on buggy  
behaviors) binaries will work with all different copies of the  
library in the same release series.  By definition, all releases in a  
particular stable branch must not break compatibility and must have  
the same minor version number.

Hmm... I notice we said we'd do two releases (stable and unstable) at  
the same time ... perhaps we should relax that to allow a series of  
unstable releases without corresponding stable releases?
eg. starting with 1.14.0 and 1.15.0 we could release 1.17.0 and  
1.19.0 before releasing 2.0.0 (stable) and 2.1.0 (unstable)
I can see that that might be useful if we ever wanted to do major  
changes to a library while keeping a single stable branch because we  
expect the major changes to be done relatively quickly and don't want  
to confuse packagers by offering a lot of 'stable' releases over a  
short period of time.
Or maybe we should just leave the policy as it is.