Hi Richard,
A clear document, the only thing I miss is a rationale for the use of
the SONAME with a major.minor structure, instead of the more common
major. I think this would help in the understanding why, and resulting
in less discussion.
I could even imagine that you use the SONAME major for make and base,
while keeping major.minor SONAME for gui/back unit they hit 1.0. Just an
idea.
Thanks,
Dennis
Richard Frith-Macdonald wrote:
Not sure this got through ... so resending
Begin forwarded message:
From: Richard Frith-Macdonald
Date: 5 October 2006 11:28:37 BDT
To: Adam Fedor [EMAIL PROTECTED], Gregory John Casamento
[EMAIL PROTECTED], Nicola Pero [EMAIL PROTECTED]
Cc: Developer GNUstep gnustep-dev@gnu.org
Subject: Versioning/release policy proposal
This is a proposal for conventions to be adopted for releasing
GNUstep packages ... the idea being that something like this could be
added to our FAQ and used as a reference for making releases and to
some extent guiding what changes we allow into trunk in SVN.
I'm CC'ing this to the developer list for information purposes, but I
lack the time to respond to comments directly (especially if this
gets a lot of flaming etc) other than those from GNUstap
maintainers. I'm aware that not everyone can be pleased. but I've
made my best attempt to satisfy people, and I'm hoping that Adam,
Gregory and Nicola will broadly agree and add any final polish taking
any other opinions into account.
1. Release Version Numbering scheme
We retain the current major.minor.subminor version numbering scheme
for releases and for naming tags in svn.
eg. when making a release of version 1.2.3 of package foo the svn tag
is foo_1_2_3.
This is clear, conventional, and well understood.
2. Library Version Numbering scheme
We retain the current link between release versions and library
(SONAME) versions ... in that changing the major or minor version
number of a release also implies changing the library version number,
but changing the subminor number does not. So release 1.2.3 of
package foo implies library libfoo.so.1.2 as does
release 1.2.4 etc. This provides a clear and simple link between
release version and library version while allowing us to make
releases without having to change the library version we expect apps
to link to.
3. Policy on changing version numbers
We change the minor version number (and therefore the library
version) when we break backward compatibility . This will mean that
most releases we make will only change the subminor number rather
than the minor number even where we have added substantial new
features. While I realise that this has a problem with public
perception being that the project is dead because it never makes
'big' new releases, I think it's better to address the problem with
improved publicity of what's in the new release rather than by hoping
that a big version number change will do it for us. On the rare
occasion where we want a big public change, we would change the major
version number (and of course SONAME).
4. Release stability policy
We advertise a 'stable' release *every* time we break backward
compatibility. Doing this requires making two releases pretty much
at the same time and bumping the minor version number for each. Eg.
if the last release was 1.3.24 then we release 1.4.0 as 'stable' and
1.5.0 as 'unstable', each with the appropriate change in the SONAME.
All releases (if any) in the 1.4 family would be bugfix releases.
I suspect the vast majority of people would just use the 'unstable'
releases (largely defeating the point of having 'stable' ones), but
the overhead of doing a 'stable' release is very low, so I don't see
why we shouldn't do it.
We can make 'stable' releases be those with even subminor version
numbers.
5. Standard release procedure (backward compatible with previous
version)
a. tag the version for release using the name_major_minor_subminor
convention.
b. make tarballs and installation packages
c. bump the subminor version number in trunk
d. put release on ftp site and publicise
5. Standard release procedure (NOT backward compatible with previous
version)
a. bump the minor version number and SONAME and reset the subminor
number to zero
b. tag the version for release as 'stable' using the
name_major_minor_subminor convention.
c. make tarballs and installation packages
d. bump the minor version number and SONAME and reset the subminor
number to zero
e. tag the version for release as 'unstable' using the
name_major_minor_subminor convention.
f. put releases on ftp site and publicise
6. Bugfix release procedure
a. if this is the first bugfix release of a package version, make a
branch from the tagged release using the tag name as the branch name
eg. if the release was tagged in svn as foo/tags/foo_1_2_0 then the
branch is foo/branches/foo_1_2_0
b. apply bugfixes to the branch
c. tag
