Aren't we, in theory, supposed to be doing this already? At the very least the old plan should be the strawman proposal we begin with, considering how long we spent hashing it all out.
-Colin (via thumbs) On Jul 26, 2011, at 4:45 PM, Paul Wilde <paulwi...@gmail.com> wrote: > Something I'd like to suggest whilst we're on the subject of releases is > maybe adopt a similar release cycle to Google Chrome once 1.5 is released. > Mozilla (Firefox) have just now adopted this as well. > > 1.4.2 was released 7 months after 1.4.1, that's a long time when a few of > those tickets were fixed within a month or two of 1.4.1 being released. 1 or > 2 releases could of potentially been made in between 1.4.1 and 1.4.2 to give > users bug fixes faster. > > So basically what I'm trying to say is rather than having fixes and features > sat on a branch for 1-2 years begging to be see the light of day whilst > waiting for the rest of the features to be completed, instead release what's > there (assuming its release quality of course). I know stuff has been said > previously about keeping branches in a release quality state. > > Also to ensure that stuff does actually get released set a rough timeframe of > one minor release every month with whatever fixes are committed during that > time. > > Really 1.5, 1.6, 1.7 etc don't need to hold 100+ tickets as it demotivates > people from contributing, I believe 30-40 tickets per major release is > perfectly fine. > > I know that both Adrian and Robby are in favour of this at the very least.
