[tor-dev] Nick's planned schedule for Tor 0.2.3.x development

[Nick Mathewson]

Hi, all!

I'll try to avoid a long-winded mail and instead cut to the chase: I
want Tor releases to come out more frequently, and I'm going to plan a
release schedule for 0.2.3 to make sure it happens.

It's July 2011 now; I want to get 0.2.3.x released in early 2012.  To
that end, I'm going to declare the following tentative and somewhat
arbitrary schedule:

December 1, 2011: Big feature freeze.  No new features that "feel big"
to me get merged into 0.2.3.x after this date, barring exceptional
circumstances[*].

January 6, 2012: Feature freeze.  Barring exceptional circumstances,
no new features get merged to 0.2.3.x after this date, barring
exceptional circumstances[*].  Fixes for non-regression bugs (that is,
those that also existed in 0.2.2.x) may also get deferred if they
aren't too severe.

Some time between Jan 6 and Jan 30: we fork off a maint-0.2.3 branch
and have master become 0.2.4.

When it's ready, 2012: We release 0.2.3.x-rc, see how long everything
took us, and adjust our plans or 0.2.4.x.

Note that the deadlines above are _merge_ freezes, not _submission_
freezes.  If you give me a big patch on Dec 1, and it needs more
review or revision than can get done that day, then it needs to wait
for 0.2.4.

Obviously, this is still up for discussion.  But please remember about
the bikeshed.  Also, please keep the following in mind:

   * Delaying a release in order to merge "one more feature" means
that every *other* feature in the release gets delayed so that the
"one more feature" can hit stable earlier.
   * If we can actually get releases out on a 7-9 month schedule (or
better), the impact of making a feature wait for the next release
becomes less severe than it's been in the past.

[*] Let's not waste time trying in advance to enumerate exceptional
circumstances.

yrs,
-- 
Nick