----- Original Message ----- > 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,
I don't like this. It's probably just a three day period, but I don't like the idea of it. When we decide to freeze, shouldn't we just branch? > 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). I'm not too concerned in that regard, because most people are using our -unstable releases anyway. The only trouble is that they usually have to be told. > -- leif i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/