I'm rethreading this under "implementing version numbering", because
I'd like to distinguish it from the thread about goals, on which we
seem to have consensus. Please keep the implementation discussion in
the new thread, if it's not too much trouble, thanks.
Branko Čibej <firstname.lastname@example.org> writes:
> John Peacock wrote:
> > email@example.com wrote:
> >> Our interim releases ("0.x.y") are over, once 1.0.0 comes out. We
> >> need a new naming strategy. Using "1.1.0" as an example -- this
> >> applies equally well to any stable version triplet -- let's do suffix
> >> qualifiers:
> >> subversion-1.1.0-beta1.tar.gz
> >> subversion-1.1.0-beta2.tar.gz
> >> subversion-1.1.0-beta3.tar.gz
> >> subversion-1.1.0.tar.gz
> >> I think it's fairly clear that the "betaX" marker is leading *to* the
> >> release number on the left; have seen this strategy used by other
> >> software packages, anyway. We can use "alpha" instead of "beta" when
> >> we feel that tentative, but in general "beta" is probably fine.
> > I re-attach my proposed way to handle this (I used 'RC' instead of
> > 'beta', but you get the idea). It would even be possible to do
> > 'alpha', 'beta', and 'rc' using different negative values for
> > SVN_VER_MICRO (alpha = -1, beta = -2, rc = -3). This makes it very
> > easy for the release manager to just increment SVN_VER_SEQ instead of
> > hand-editing some #define for only those releases.
> I don't understand why you'd want to introduce a fourth level of version
> numbers. We use SVN_VER_TAG (and SVN_VER_NUMTAG) to mark prereleases.
> Here's how svn_version.h would look like on trunk after 1.0:
> Index: svn_version.h
> --- svn_version.h (revision 8533)
> +++ svn_version.h (working copy)
> @@ -48,14 +48,14 @@
> * Modify when incompatible changes are made to published interfaces.
> -#define SVN_VER_MAJOR 0
> +#define SVN_VER_MAJOR 1
> /** Minor version number.
> * Modify when new functionality is added or new interfaces are
> * defined, but all changes are backward compatible.
> -#define SVN_VER_MINOR 37
> +#define SVN_VER_MINOR 1
> /** Patch number.
> @@ -73,26 +73,29 @@
> /** Version tag: a string describing the version.
> - * This tag remains "dev build" in the repository so that we can always
> - * see from "svn --version" that the software has been built from the
> - * repository rather than a "blessed" distribution.
> + * This tag remains " (dev build)" in the repository so that we can
> + * always see from "svn --version" that the software has been built
> + * from the repository rather than a "blessed" distribution.
> * During the distribution process, we automatically replace this text
> - * with something like "r1504".
> + * with something like " (dev build r1504)".
> + *
> + * On the release stabilization branch, this macro will be " (alpha)",
> + * " (beta 1)", " (release candidate 1)", ... and "" for final release
> + * versions.
> -#define SVN_VER_TAG "dev build"
> +#define SVN_VER_TAG " (dev build)"
> -/** Number tag: a string indicating whether this is a released version.
> +/** Number tag: a more compact description of the version.
> * This tag is used to generate a version number string to identify
> * the client and server in HTTP requests, for example. It must not
> - * contain any spaces. This value remains "+" in the repository.
> - *
> - * During the distribution process, we automatically replace this text
> - * with "" to indicate a baselined version.
> + * contain any spaces. This value remains "-dev" on trunk, and changes
> + * to "-alpha" or "-beta" on the release stabilization branch, and ""
> + * for final release versions.
> -#define SVN_VER_NUMTAG "+"
> +#define SVN_VER_NUMTAG "-dev"
> /** Revision number: The repository revision number of this release.
> @@ -117,7 +120,7 @@
> #define SVN_VER_NUMBER SVN_VER_NUM SVN_VER_NUMTAG
> /** Complete version string */
> -#define SVN_VERSION SVN_VER_NUM " (" SVN_VER_TAG ")"
> +#define SVN_VERSION SVN_VER_NUM SVN_VER_TAG
> Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jan 29 22:39:25 2004