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 <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 Sat Oct 21 14:36:44 2006