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

Re: svn commit: rev 209 - trunk/subversion/include

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-10-05 06:40:40 CEST

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

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