Looking over the STATUS file, and the current state of two
vetoed-but-in-discussion issues, I think we can finally schedule the
1.0 release. Ben Collins-Sussman, Greg Stein and I chatted about
this, and thought that four weeks of soak time for a candidate tarball
(before we call it 1.0) is about right. Hope y'all agree.
So:
* Tonight and tomorrow:
Merge in all the approved changes. [I'd like to do this;
search for "regarding merging" below for details.]
* Wait a few days while any further bindings adjustments happen.
The ones already approved will already be merged in, of course.
But I think some bindings developers will want to start from the
post-merge state and see what's broken, and that will produce new
bindings changes. That's fine. Since we've agreed to be looser
about the bindings anyway, I'm wondering if we shouldn't reflect
that in a less formal process for them (yes, this backs off a
position I took earlier). I'll post a separate mail about that
next. Anyway, since these adjustments will be API tweaks, we can
probably have them all in by...
* Tuesday, 13 January:
Snap release 0.36 from the 1.0-stabilization branch. There's no
additional soak time here, we just make the release and put it
out there, as the first 1.0 candidate tarball.
* Tuesday, 20 January [anticipatory]:
Snap 0.37 release. If we've found bugs in 0.36, we take care of
them here. Also, by then the date parser thread should be
resolved, and there may be a change to fold in; same with the
#1682 thread.
* ...soaka soaka soaka...
* Monday, 23 February
Release 1.0. This is a little more than 4 weeks from Jan 20th.
(Really, February 17th would be 4 weeks. The extra few days are
from a latent conservatism... And because the 23rd is Sander
Striker's birthday. And also, uh, mine. So there :-) ).
I don't really expect this to slip. We've been conservative even with
trunk lately, as well as the 1.0 branch. In effect, our soak time
started quite a while ago.
Thoughts?
Oh, regarding merging: I think it'll be easier if one person does it.
I'd like to be that person. My plan is to apply committed changes
roughly in order (to avoid spurious conflicts), then take changes from
issues, and commit the whole shebang in one commit. This is okay
because we already *have* the changesets in all cases -- either as
revisions, or as patches. That way I can do my 'make check's once.
But, if any change requires non-trivial adjustments to be applied,
then I'll do that one in a separate commit, because the adjusted
change is not captured in any existing changeset, of course.
The birthday proximity was, I promise, a coincidence, and I'll happily
change my birthday to avoid any appearance of a conflict of interest.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 9 00:11:50 2004