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).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 30 04:49:35 2006