--On Sunday, April 3, 2005 4:07 AM -0700 Ben Reser <ben@reser.org> wrote:
> 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.
No, because the RM has to say, "*This* is 1.1.4." The committers (as a whole)
are then the ones who say, "1.1.4 is a public release" (or not). The
committers can't collectively decide what goes into the release - that's the
RM job, in my view.
The problem with your approach is that there could be multiple "1.1.4"
releases and that could be really confusing. There should only ever be one
"1.1.4" - once the tarball is posted anywhere, the release is done and not
modifiable in anyway. It must stand on its own merits then.
> 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.
No, I'm saying that the tag should appear before (or at the same time) it ever
appears publicly in any fashion.
> 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.
No, but it modifies the release and the contents of the release. Hence, it
belongs in the tag.
> 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.
FWIW, in httpd, the rule is that you could re-roll a release if the
environment is busted (discretion is left to the RM). But, you can not change
the code in *any* fashion. So, re-rolling because of a busted libtool would
be fine for httpd and wouldn't necessitate a version bump. Any typos in a
file or error in compilation would mean that the version has to be bumped.
> 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.
But, the tag must be the authoritative claim that 'this' is the code that
produced the release.
> 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.
Again, we differ as to when the release is created. I view the release as
created once the RM posts a tarball for approval. You view it as created once
it is approved. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 3 18:42:00 2005