Release schedule plans

[Maxwell Kanat-Alexander]

> what about amalgamating the existing code for
> 2.18 and 2.20 into one release, and *calling* it 2.18?

  I was thinking about that all last night while we were discussing the plans. I hate that idea, but only because it pushes 2.18 out further, and it's been SO HARD to get 2.18 out the door. We've already gotten all the release blockers out of what we're calling "2.20", though, for the most part, and it's *not very different* from 2.20.

  And yet, I almost want to do that. It will make branch maintenance so much easier...

  But there are too many "blocking2.20?" bugs, and we wouldn't be unfrozen before March. We'd end up in this situation again, with a freeze affecting tip development. I think we should release 2.18 -- it works, it's releaseable, and we NEED to release something.

  If branch management is the long-term concern, then we should release the hold on 2.20 for now and freeze again for it in March. That will still give us only about 7 - 9 months of open development on 2.20, which should be easily manageable.

  -Max