So I've been wondering... Why are we sticking to released versions of
Subversion on svn.collab.net?
In the past we used to run reasonably current development snapshots (ok,
so that's the only kind of snapshot that existed at the time, but
still), and it let us catch problems that would not ordinarily be
noticed during development. If we'd been doing the same thing with
1.1.0 release candidates we would have had a shot at noticing the 'svn
list' slowdown before releasing it into the wild.
I'll note that the Apache guys seem to have a policy of running release
candidates of httpd on apache.org before cutting a release, and it seems
like a reasonable thing to do.
Plus, with our backwards compatability policy we shouldn't be causing
problems for people trying to access the repository by running more
bleading edge versions of svn on it, and even if we do have an
occasional problem it would be a good way to shake out version specific
issues, since I suspect svn.collab.net gets hit with a wider variety of
svn versions than anyone actually tests with on a regular basis.
So I'd like to propose a policy of testing RCs on svn.collab.net before
rolling out an actual release, and beyond that, I think it might be
worthwhile to upgrade to dev snapshots of trunk from time to time in
order to shake out problems before they become too intrenched. Perhaps
that would only be done as we get closer to 1.2.x being released, I'm
not sure how the best way to do this would be, but it seems like
something worth discussing.
Any thoughts?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 10 06:54:13 2004