Karl Fogel wrote:
>How does this policy sound:
>
> subversion-0.18.0.tar.gz -- unpacks into subversion-0.18.0/,
> always corresponds to tags/0.18.0/.
> 'svn --version' just prints "0.18.0",
> doesn't include a revision number.
>
> subversion-0.18.1.tar.gz -- unpacks into subversion-0.18.1/,
> always corresponds to tags/0.18.1
> 'svn --version' just prints "0.18.1",
> doesn't include a revision number.
>
>And so on. Since these are branch releases now, it's time to lose the
>revision number from the tarball name.
>
>Meanwhile, for subversions built from a trunk working copy, we just
>have 'svn --version' print out the revision number. That is, instead
>of
>
> svn, version 0.17.1 (dev build)
>
>it will say
>
> svn, dev build, revision 4960
>
That's not good. People will want to know the last released version
previous to a build.
>or somesuch. This is possible now thanks to Philip's 'svnversion'
>program, which see.
>
So are you suggesting we run svnversion as part of the build process? If
so, I invite you to hack that yourself, instead of fobbing it off on an
unsuspecting RM volunteer. :-)
>What do you think? This would mean that dist.sh, and possibly a few
>other things, would need some tweaks, but it will make things a lot
>clearer in the long run. Up for it?
>
>
Can we please, please stop fooling around with this? Let's just admit
that our labelling strategy is less than perfect, and just leave it at
that.Or we can just document that the revision number in the version tag
always comes off the release branch, not the trunk -- end of problem.
--
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 Wed Feb 19 20:35:14 2003