----- 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/

Reply via email to