On Sat, Apr 02, 2005 at 05:34:05PM -0800, Justin Erenkrantz wrote:
> The confusion here is to when is the release created:
>
> - I believe the release is created when the RM posts tarballs for approval.
> At that point, the version number is 'gone' and can't be modified. Nothing
> else can be called that release in any unambiguous manner. For example, we
> should never have two files claiming to be 1.1.4. Therefore, we should
> remove the ambiguity and lay down the tag as soon as the tarballs are
> created by the RM.
RM's don't decide what the release is, we just manage the process and
do some of the foot work. The tarball you cut isn't 1.1.4 officially
until the committers say it is. It's a proposed 1.1.4. That's how I've
always looked at it.
By what you're saying the RM has a great deal more power than I ever
felt like I had. Just becuase I generated a tarball didn't mean I'd
made a given release number. It meant I'd produced something for the
developers to decide if it was that release number.
> - My understanding of your position is that the release isn't created until
> the announcement is sent. At any point until then, the tag can be changed
> by the RM. (If I misstate your position, please correct me. I'm only
> trying to understand your position better.)
The tag wouldn't be made until just before the announcement. That's how
I always did it.
> My concern with your approach is that a tag would not appear when it should
> have otherwise appeared. I believe that the version numbers are cheap and
> that if it fails approval, the release still exists - it just wasn't made
> public.
I don't think it was ever a release if we don't approve it as a release.
If we toss the version number to avoid confusion, that's fine. But if
it isn't signed off on by the other committers, it's not a release. The
official announcement isn't what elevates the tarball to release status
the consensus of the committers does. We've done this very informaly in
the past, we're trying to be more formal now. But I don't think this
has ever really changed.
Why do you think the tag should appear at the point of tarball creation?
I have regenerated the tarball several times because I found mistakes on
my part without upping the revision number. As long as I don't post the
tarball publically anywhere I'd just leave the version number the same.
Granted in the past the timeframe between tarball creation and
announcement has been much tigheter. But I don't think the tag is all
that useful. It's just a shorthand way of referring to the specific
revision and branch we cut the release from. The only extra the tag has
is that it has a release marked svn_version.h which for testing purposes
is competely irrelevent anyway.
> Historically, it's interesting to see why a release failed - this allows
> people (and RMs) to learn from previous mistakes. Therefore, yah, I'm not
> opposed to keeping a record of 'failed' releases - in the hopes that people
> down the road will learn why a release failed and not make the same mistake
> again...
I'm not sure how you're going to figure that out for the tag. There's
not going to be anything in the logs saying why it was a failed release.
The only way you'd know that tag was a failed release was by knowing it
or by reading it from outside the repo. Further, there might not be
anything wrong with the tag. A dud 1.1.4 tarball could have an
identical set of files to a 1.1.5 tarball with only differences made to
the environment the tarball was produced in.
For example if the wrong version of libtool was installed... The
tarball is the definitive thing we need to be approving. Not the tag.
The tag just needs to be a copy of the source of the export that dist.sh
used with the correctly modified svn_version.h.
Nobody can use the tag as a way of signing off on a release. Becuase
the tag isn't the entirety of the release or the way the vast majority
of our users receive our software.
Honestly, I think part of the difference here is that I think you should
be able to take the repository and be able to tell what is going on from
it. But with your tags for things that we don't ever actually treat as
"offical releases" there's no way of telling that from the repository...
You're suddenly relying on all kinds of things like mailing list logs
and IRC logs to figure out what is going on. And in my experience that
stuff isn't always reliably archived.
> >What harm is calling it 1.1.4-test going to be until we refer to it as
> >"official?"
>
> The tarball isn't called subversion-1.1.4-test nor would the svn_version.h
> refer to it as 1.1.4-test. Therefore, I believe that the tag should
> reflect what the tarball reports.
The point here is to use a temporary name to avoid confusion on the part
of people external to the project. When we've decided the tarball is
good or bad we'd rename or remove the 1.1.4-test path. If we didn't
have a separate dir for release tags I'd just delete it, but I'm not
terribly against have a 1.1.4 tag for an unreleased version number
provided that the 1.1.5 exists... I.E. I'd probably leave it as
1.1.4-test until 1.1.5-test was renamed to 1.1.5.
If we have a separate directory for release tags then using this isn't
really necessary. We can just tag 1.1.4 in tags, and then move it to
releases just before the announcement. If we toss the tarball and do
1.1.5 then we just never move it.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 3 13:08:28 2005