[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r8796 - branches/1.0.0-beta1

From: <kfogel_at_collab.net>
Date: 2004-02-23 01:18:03 CET

Philip Martin <philip@codematters.co.uk> writes:
> > Create release 1.0.0-beta1 branch
>
> Ummm... what's the procedure here? I don't see any benefit in a
> 1.0.0-beta1 branch. Why not make the beta1 commits straight onto the
> 1.0.x branch?

Okay, here's the promised answer, sorry for the delay, Philip.

First of all, you're right: in the long run, we shouldn't need to make
a separate branch/tag for each beta1, beta2, etc release.

However, at the moment, there's a small problem in svn_version.h. To
understand it, it helps to think of SVN_VER_TAG and SVN_VER_NUMTAG as
one entity -- let's call it "SVN_VER_THING" -- since they're really a
single concept that's split into two constants for convenience (hence
the need to keep them in sync at all times).

The problem is that SVN_VER_THING is currently used both to indicate
that this is a "dev build" (i.e., a working tree build), XOR that this
is a release with a qualifier such as "beta1".

So watch what happens when we try to release subversion-X.Y.Z-beta1:

   1. We change SVN_VER_THING from "dev build" to "beta1".

   2. We make the release.

   3. Uh... right... er, now what do we do?

If we change SVN_VER_THING back to "dev build", one can't immediately
tell, from looking at a posted bug report's 'svn --version' output,
whether it used a working tree from before the beta1 release or after.
(Yes, one could look at the revision number and compare it against
CHANGES or the logs, but that means leaving your mailreader, so we've
already entered a whole different universe of involvement.)

And if we don't change it back to "dev build", then working copy
builds of 1.0.x will look like they're tarball builds. Badness :-).

If we ever have to fix a real bug and release beta2, all this becomes
a real problem.

The long term solution, of course, is that the bits for indicating
dev-build-or-not-dev-build must be completely independent of all the
release number parts, including any "alpha1", "beta1", etc. Then, by
controlling when we bump version number parts, we can *always* treat a
Subversion that says "dev build" as being from a working tree at or
after -- but never before -- the release number claimed by that
Subversion.

I believe Brane and John Peaock had the forsight to be involved in a
discussion about this a while ago, but unfortunately we didn't get it
resolved by 1.0.0. That's okay, we can cope by using SVN_VER_THING
for now, it's not the end of the world.

However, I wanted to avoid changing SVN_VER_THING away from and then
back to "dev build" in the 1.0.x line, so recommended a separate
branch for 1.0.0-beta1. At least now if we see "beta1", we know it
was either made from the tarball, or from a branch/tag *very* similar
to the tarball -- and even the latter is extremely unlikely, as no one
but Josander or me had any reason to check that branch (whereas many
people have 1.0.x lines checked out).

Make sense now?

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 23 02:21:11 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.