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,