[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Release policy question

From: Greg Stein <gstein_at_lyra.org>
Date: 2006-01-30 04:05:16 CET

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

This is an archived mail posted to the Subversion Dev mailing list.