On Thu, Feb 21, 2002 at 04:23:57AM +0100, Branko �ibej wrote:
> Greg Stein wrote:
>...
> >In Apache, the CVS repository (therefore, all developer builds) always say
> >something like "2.0.33-dev", meaning that it is being developed towards
> >2.0.33. At release time, the -dev is dropped.
>
> Heh. So Apache stores the suffix in the repository, and you say that's
> good; but so do we, and you say that's bad.
Different. Apache inserts a thing that says "this was built by a developer".
That is different than inserting something stating the quality of the
release. The quality is not determined at the time a tarball is snapped.
> >In our terms, we could have a label that says "dev" and then replace that in
> >the "dist.sh" script with the correct revision number. Thus, if people
> >report that they are using a "dev" version, we can be suspicious. If they
> >report a specific revision, then we know it came from a distro, and what
> >revision it was.
> >
> >Note that this is somewhat orthogonal to including a state / quality level
> >in the codebase.
>
> No, it is *not*. You could just as well argue that maintaining the
> version number in the code base is wrong. After all, version numbers are
> nothing but marketing fluff, if your SCM process is solid.
I agree with the marketing fluff comment :-) In fact, that is partly why
(code)names are used for releases of SourceCast inside CollabNet. The
engineering codes for a (named) release, and later on the marketing guys
decide how they feel like numbering it :-)
However, to have some record of "where you are" in the version numbering,
they have to be stored somewhere. Otherwise, it falls to some out-of-band
human bookkeeping to keep track of the "marketing" numbers. Thus, I believe
they belong in source control.
> Anyway, I absolutely agre with Zack (not surprising, as I modeled our
> svn_version.h file based on what gcc does). We should have a script that
> does the Right Thing with the version numbers, suffixes, etc. I've said
> before and I'll say again: the state of the code is part of the
> configuration. You either keep it all under version control, or you
> throw it *all* out (including versin numbers).
We create tarballs before we know the state of the code. That is part of our
process (for better or worse :-). GCC knows their state before the snaps
because they have a different process.
Personally, I like lightweight and flexible processes, and I feel the GCC
"create a branch and let it sit for two months" is a bit burdensome. Not to
mention on a totally different kind of schedule than us :-) That means that
we'll have a general impression of the code state (e.g. we're pre-alpha now,
we'll be alpha in N weeks, beta sometime later, etc), but when we snap a
tarball, it could be horribly broken on some platform. Or maybe a last
minute checkin horked property commits. Or who knows what...
Well... it seems that I've heard a number of +1 to remove the "rc2" type
tagging (and fewer +1's to keep it), and shift that to the release process.
As always, we can debate further on where to put the 0.9.x type stuff. :-)
Cheers,
-g
--
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:37:09 2006