Subversion 1.5

Over the past couple of weeks, I've been thinking a lot about the next
release, Subversion 1.5. For what it is worth, these are my thoughts
about 1.5 and its relationship to merge tracking. In IRC this
afternoon, a number of other people also made similar comments; this
thread can serve as a clearinghouse for those ideas also.

It took nearly 4 months to stabilize 1.4, and it will likely take that
long to stabilize a release with merge tracking. This isn't a comment
on the quality of the merge tracking code, of course. Merge tracking is
just Hard, and we will likely encounter interesting bugs during the
stabilization process. Given that the merge tracking branch probably
won't be merged to trunk for another month or two, that puts a release
with merge tracking into the Q3-Q4 2007 time frame, optimistically.

Since 1.4.x branched 10 months ago, many features and fixes have gone
into Subversion. These include:
 * Cyrus SASL support (Vlad's SoC project '06)
 * Copy/move improvements (Peg revision support, support 'svn mv file1
   file2; svn mv file2 file3', support 'svn cp *.c dir')
 * Dav mirroring
 * Cancellation improvements
 * JavaHL improvements
 * Partial sparse directories support
 * Changelist support

That being said, I propose the following. First, someone should update
CHANGES. Not only will that help decrease the amount of work needed
when it actually comes time for the next release, but it will give us a
more quantifiable look at what is in trunk now.

Second, should the number of changes be substantial, we branch 1.5.x,
and do an intermediate release without merge tracking. We could branch
as early as the end of this month. This would give us a chance to
stabilize existing features without having to hold up the release while
also stabilizing merge tracking. When the merge tracking release does
come, we can focus better on fixing those bugs. As with CHANGES, this
is work that will have to be done eventually, so why not now?

There are drawbacks to releasing 1.5 without merge tracking, but I think
they aren't as big as the advantages. Of course, our users would like a
1.5 release with merge tracking, but I think that many of them would
also like the other features currently in trunk, without having to wait
for merge tracking.

Releasing 1.5 without merge tracking would almost certainly push the
timeline for merge tracking back, but probably not by much. The time
spent fixing bugs for an intermediate release would also have to be
spent on a merge tracking release. Doing an intermediate release may
actually help to parallelize the merge tracking development and
unrelated stabilization.

A number of API changes would be frozen for the intermediate 1.5
release, and those APIs may need to be rev'd to support merge tracking
changes. I don't see this as a major drawback, though.

What are other's thoughts about shipping 1.5 soon?

-Hyrum