I will reiterate again: I really think that encoding the *classification* of
a release *inside* the release is entirely bogus.
When a release is created, it is impossible to know the true state of that
release. "This is beta," the group says. BAM! One day out and a corruption
bug is found in the FS.
A build is created, tested, found to be decent, and labelled as alpha. But
that label is *only* on the web page. After a week of alpha being out there,
with no big problems found, we can label it a beta.
Note that we could build and release a tarball, but not even label it. Only
after some testing do we call it alpha.
The issue here is that we cannot assign a label to a build on our own. We
don't have the test teams to validate the *true* quality of the build before
releasing it. Only after a while in the wild can we truly classify it.
As such, I recommend completely dumping SVN_VER_TAG and the 6-step stuff
below. The major/minor/micro should obviously stay, the _NAME is marginal.
Cheers,
-g
On Thu, Oct 04, 2001 at 07:26:21PM +0200, Branko �ibej wrote:
> sussman@tigris.org wrote:
>
> >Author: sussman
> >Date: 2001-10-04 15:09 GMT
> >New Revision: 209
> >
> >Modified:
> > trunk/subversion/include/svn_version.h
> >Log:
> >
> >* svn_version.h (SVN_VER_TAG): Brane, I have no idea how the code can
> > possibly know its own revision; but I do know that seeing "M3
> > (r196)" all the time is confusing newbies. And nobody wants to
> > update this number before each commit. Commenting out for now.
> >
> Yah.
>
> What I actually had in mind was something like this:
>
> * Make the checked-in SVN_VER_TAG "development" or "prerelease",
> depending on the state of the tree.
> * When creating a development tarball,
> 1. check out the tree
> 2. change SVN_VER_TAG to "r$(($head_revision + 1))z
> 3. check in svn_version.h
> 4. if current $head_revision is greater than SVN_VER_TAG, back
> to (2)
> 5. roll the tarball
> 6. change SVN_VER_TAG back to whatever it was before
>
>
> For a release tarball, the process is similar, except that in (2) you
> #undef SVN_VER_TAG and make sure the version numbers are right.
>
> All of this can be done by the distrib script. It's on my list of things
> to do, as a matter of fact.
>
> (If you try out my latest Win32 binary, you'll see why the tag can be
> useful. :-)
>
> --
> Brane Cibej <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
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:44 2006