To avoid even further delays and instabilities for our 3.0 release, I'd
like to make three proposal:
1) A hard release date for v2.1.9 of 5/30/2011 (it's a Monday). This
means we'd have to cut the release the morning of 5/27 to give it a 72
hour vote.
2) Any new feature or improvement (not bugs) that is not completed by
this date gets moved to v3.1, and we'll prioritize development on these,
and then make a v3.0.1 release with the important things that are
missing from v3.0. We'll go through the bug list after v3.1, and make a
prioritization.
3) After v2.1.9 is released, no new features or improvements on trunk,
it should be considered frozen until we make the v3.0 release. All
commits on trunk after v2.1.9 must be discussed and voted on per the
STATUS file (so, we'll consider trunk stable after v2.1.9 until v3.0 is
released). After v3.0 is released, we'll open up trunk again, and focus
on the missing pieces as per item #2.
Thoughts? Concerns? I know it's less than ideal to put constraints like
these, but we're hurting for not having made a stable release in over a
year (other than 2.0.1, which was very, very minor).
-- leif
- [PROPOSALS] Releases of v2.1.9 and v3.0 Leif Hedstrom
-
