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

Re: 0.35 => Beta => 1.0 schedule

From: <kfogel_at_collab.net>
Date: 2003-12-05 01:56:54 CET

Greg Hudson <ghudson@MIT.EDU> writes:
> I reiterate that we should consider limiting ourselves to making
> version-numbered releases on stable branches only, and not making
> "development" releases. If you look at the larger body of free software
> projects out there, most of them do not make a frequent practice of
> making development releases after they reach 1.0. The big example of a
> project which does so is the Linux kernel, which historically hasn't had
> a publically accessible repository to pull from. (And it has much less
> frequent development releases now that it does have such a repository.)

Hmmm. That's true for most projects most of the time, but as they
approach a new release, many projects *do* start releasing bleeding
edge tarballs for testing. In our case this is particularly
important, because finding bugs is so dependent on testing with a wide
variety of data and usage patterns. The developers alone could never
do it thoroughly enough; we need those adventurous users, and the
tarballs make it convenient for them to help.

I'm not sure how we'll determine when to start making those
development releases again. If you're arguing that we not start doing
it immediately, but rather only make development sources available
from the repository for a while, I could see that being a good
strategy. It certainly reduces the burden on the release manager.

But at some point, IMHO sooner rather than later, we'll want to make
dev tarballs available again, and when we do, they'll need names.
What should those names be?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 5 02:43:42 2003

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.