Re: version numbering and release lines

John Peacock wrote:

> kfogel@collab.net 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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org