Greg Stein wrote:
>On Thu, Jan 29, 2004 at 10:35:14PM +0100, Branko ?ibej wrote:
>
>
>>...
>>+++ svn_version.h (working copy)
>>...
>> * During the distribution process, we automatically replace this text
>>- * with something like "r1504".
>>+ * with something like " (dev build r1504)".
>>
>>
>
>During a distribution, this becomes " (r1504)". It obviously isn't a dev
>build :-)
>
>
Ah, yes, semantic tidbits. O.K., "during creation of a snapshot
tarball", iff we ever create snapshot tarballs. :-)
>>+ *
>>+ * On the release stabilization branch, this macro will be " (alpha)",
>>+ * " (beta 1)", " (release candidate 1)", ... and "" for final release
>>+ * versions.
>>
>>
>
>I'd say "no" on this. We still want to indicate "somebody built this from
>a working copy; it isn't an alpha/beta/whatever release."
>
>
So you're suggesting that we get the -beta, -rc and whatnot tags only in
tarballs? That's fine, as long as there's something in the repo that
indicates the code is moving towards a release; -prerelease would be fine.
>>...
>>-/** 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"
>>
>>
>
>This change implies a variance in the release process. Specifically, that
>post-release, we bump the number. Thus, after a 1.0.1 release, we bump the
>number so this becomes 1.0.2-dev.
>
>
Yes.
>But I've grown to dislike that pattern. In particular, you might not know
>what the number is supposed to be. Or maybe you bump it "too far". This
>happened to me with ViewCVS where one of the committers bumped it from 0.9
>to 1.0 (so it now reads 1.0-dev). Unfortunately, I'm now stuck because if
>I try and back away from that, a release will look like it is older than
>the 1.0-dev installs out there. And I would prefer if the next release was
>*not* 1.0; there has been too much change which needs to be tested (by
>distributing a release to the masses).
>
>
So? If somebody installs something that was not released, that's not
your problem. I recognize that this happens all the time in the open
source world, but...
>Thus, I prefer that we continue with the "+" marker to mean "this is like
>1.0.1, but additional stuff has been changed."
>
>
...this is a problem: both the tip of trunk and the tip of the stable
branche(s) must somehow indicate development/unreleased status. In your
scheme, right after the 1.0 release, _both_ branches would say "1.0.0+";
and worse, after a 1.0.1 release, the stable branch would havs "1.0.1+"
and trunk would still have "1.0.0+", which is nonsense to me.
Also, I don't think the problem you describe with ViewCVS applies to the
post-1.0 world we're envisoning for SVN. On average, we'd probably have
one or two stable branches, and one (or, in very extreme cases, two)
development branches. Imagine the most extreme scenarion, where we're
for some reason maintaining one current release branch, two old patch
branches, the trunk, and a development line for the next major release.
With my scheme, we'd get the following numbers:
Branch Version
/trunk 1.2.0-dev
/branches/1.0.x 1.0.13-dev
/branches/1.1.x 1.1.3-dev
/branches/r2-dev 2.0.0-dev
I don't see _any_ problems. so somebody installs 2.0.0-dev, and our next
release is 1.2.0; or somebody installs 1.2.0-dev, but we release 1.1.3
first, or somebody installs 2.0.0-dev but we never make a 2.0.0 release.
So what? The numbers come from different branches, which is instantly
visible from the version numbers, given our release policy; and the
status of the code is obvious from the tag on the release number. I
think your ViewCVS example can only be a problem in a pre-1.0 situation,
when you make releases from the development branch. But we avoid that by
_not_ changing version numbering on trunk before rolling 1.0, so I don't
think your concern applies.
--
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
Received on Sat Jan 31 00:33:38 2004