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.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
