You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2001/10/04 17:26:21 UTC
Re: svn commit: rev 209 - trunk/subversion/include
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))ďż˝
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 �ibej <br...@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
Re: svn commit: rev 209 - trunk/subversion/include
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
>I will reiterate again: I really think that encoding the *classification* of
>a release *inside* the release is entirely bogus.
>
I will reiterate again: I don't agree with you.
>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 whole point of release management is that you *do* know the status
of a configuration (I mean configuration in the SCM meaning of the word
here). Would you accept non-essential patches during beta phase? You
would not.
Of course problems will crop up after you bless a revision with
"status". They always do, even after releases. In that case you fix the
problem, and roll another beta, or a patch release, or whatever. Of
course, you try to avoid such problems, which -- again -- is what
release managment is for.
>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.
>
Oh nonsense. Long before you want to define the status of the a build,
you know how stable your tree is. You can even use a two-phase process:
release a tarball, call it "beta candidate", have people test it; then,
when you're satisfied the quality is acceptable, change *only the
version tag* and call that "beta". (This is exactly what I proposed,
except that I also aknowledge the existence of development snapshots,
without "status".)
Then when a bug crops up the next day -- if it's serious enough -- fix
it, and release "beta2".
If it works for gcc, and python (yes, the python 2.2 alpha Win dll has
version info that says it's an alpha version), and a lot of other
software, I don't see why it wouldn't work for Subversion.
After all, you have to set the version number somehow, too -- you have
the same problem there.
>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.
>
Another thing the tag is invaluable for is error reporting. Imagine
someone reporting an "error in svn 2.5". You ask her to send you the
output of "svn --version", and sure enough, it reports version 2.5.
How're you to know that what she actually has is actually "2.5 (beta1)",
if you don't have that tag?
The name, I agree, is marginal -- I included it so that people can see
se the same thing as our web page says. It'll go away once the version
numbers mean anything.
So, I guess we can agree that we don't agree. Luckily we have a perfect
arbiter, name of Karl, who'll have to bear the brunt of all this release
management stuff anyway, and will most likely set things up to please
himeself (after giving "due consideration" to advice from others). :-D
--
Brane �ibej <br...@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
Re: svn commit: rev 209 - trunk/subversion/include
Posted by Greg Stein <gs...@lyra.org>.
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 <br...@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