On Sun, Jan 29, 2006 at 06:13:00PM -0600, kfogel@collab.net wrote:
> Erik Huelsmann <ehuels@gmail.com> writes:
> > > I would say that if any code changes, it *must* get a new version number.
> > > If it's just a re-roll due to a dist.sh or packaging problem, then it can
> > > use the same version number. However, there is never a legitimate reason
> > > to re-use a version number if the code has actually changed. -- justin
> >
> > I agree with Justin that this is how I'd like to handle this in this
> > case: there's no difference in the code shipped, nor is there any
> > difference in any other significant part of the archive.
>
> Okay, clarified policy committed in r18287, comments welcome.
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.
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 Mon Jan 30 04:01:11 2006