Greg Hudson <ghudson@MIT.EDU> writes:
> Here are Karl's answers, as best I understand them:
>
> 1) subversion-unstable-1.1.0
> 2) subversion-unstable-1.1.1
> 3) subversion-1.2.0
> 4) subversion-1.2.1
> 5) subversion-unstable-1.3.0
Yeah, that looks right.
(An "unstable trunk release, or snapshot" still involves a branch, of
course, just a very short-lived one. Such releases are analogous to
the interim releases we do right now -- 0.35, etc -- which can be
considered snapshots from the 0.x line.)
> 6) Not yet stated
> (Prior practice is "svn, version X.Y.Z (dev build)" where X.Y.Z
> is the most recent release we have branched for, even if we
> haven't released it yet. What that means between C and D and E,
> I am not sure.)
I'm fine using a revision number to express that this is "version
X.Y.Z, plus some changes", e.g.:
svn, version X.Y.Z.rRRRR
although I think we tried this once and discovered that, even with the
assistance of 'svnversion', it was still not easy to implement
reliably. However, if that can be solved (maybe we look at the top
level README in the tree or something?), then using a revision number
is fine. Otherwise, "(dev build)" is a nice, simple solution.
To use a revision numbr, the formula is simply to take the most recent
version name in the ancestry leading up to the dev build, and tack on
the revision. Thus:
6.1) ... the trunk between A and *?
subversion-unstable-1.1.0.rRRRR
6.2) ... the release branch between * and B?
subversion-unstable-1.1.0.rRRRR [but see below]
6.3) ... the release branch between B and C?
subversion-unstable-1.1.1.rRRRR
6.4) ... the release branch between C and D?
subversion-1.2.0.rRRRR
6.5) ... the trunk between * and the time of B?
subversion-unstable-1.1.0.rRRRR
6.6) ... the trunk between time of B and time of C?
subversion-unstable-1.1.0.rRRRR
6.7) ... the trunk between the time of C and (D)?
subversion-unstable-1.1.0.rRRRR
6.8) ... the trunk between (D) and the time of E?
subversion-unstable-1.3.0.rRRRR
6.9) ... the trunk after the time of E?
subversion-unstable-1.3.0.rRRRR
(Of course, "RRRR" isn't the same every time!)
Note that in 6.2, the name doesn't indicate that it's from the release
branch, because the patch number hasn't yet been incremented on that
branch -- that won't happen until (B).
If this is a huge problem, one way to fix it is to increment the patch
number right away when we branch. That way there's no chance of a dev
build not including the new patch number. There is already a
precedent for such early bumping (it's Step 2 in notes/releases.txt).
But then we'd have to bump the patch number again right before
releasing (B).
I'm not sure it's worth it to look for a workaround here. A dev build
is inherently ill-defined, since it might be only partially updated to
the revision anyway. Having some release number, plus a revision, is
enough to tell us approximately what incarnation of Subversion the
user is running -- if we still can't determine whether they have a
particular fix, we can ask them to run 'svn log' on a file. Bug
reports from dev builds are pretty rare; reports from dev builds where
the person is not an experienced svn developer are even rarer. We
shouldn't let dev builds influence our numbering scheme very much.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 16 23:23:52 2003