On Sun, 29 Jan 2006, Karl Fogel wrote:
> Greg Stein <gstein@lyra.org> writes:
> > I would still be concerned with changes in dist.sh. That has a very
> > real effect upon the tarball. What if the new tarball picked up a
> > different copy of Neon? Or maybe used a new SWIG to generate a
> > different set of bindings?
> >
> > Point is: any new tarball can be different. And when bugs start coming
> > in, how are you going to distinguish them? This was the basis of the
> > "burn a version number. they're cheap." rule.
> >
> > If the very first release was called 1.3.1, then it is easy to
> > explain. "We rolled 1.3.0 and found problems. Thus, we rolled a 1.3.1,
> > and it was qualified for release." It's a very simple FAQ to answer.
> >
> > Yes, -rc candidate are present to try and avoid that situation (as it
> > *is* a bit strange), but it really is fine to just start burning
> > release numbers. I would much rather see a FAQ entry than an ambiguous
> > "1.3.0" in problem reports.
>
> Well, +1 here. I favor the policy you describe above more than the
> policy I just committed :-). But as far as I can tell I was the only
> one in the discussion (at the time) who felt that way, and it wasn't
> important enough to me to argue strongly for it.
>
> If you want re-make the case for the "always use a new number" policy,
> count me as one 'aye' vote. It's not a big deal to me, though, since
> we're only talking about unblessed tarballs here (and thus a
> relatively small window of time in which confusion could happen).
I too prefer Greg's suggested strategy. It's simpler, and results in
less possibility for errors when referring to a release, since it
needn't be qualified with "rcX".
--
Daniel Rall
- application/pgp-signature attachment: stored
Received on Tue Jan 31 21:29:14 2006