I am much in favor of making the beta releases available when "most"
of the bugs are flushed, and making full releases available when the
big bugs are gone (and allowing up to 6 months between full releases
might be useful).
It'd be very nice if there were some sort of "feature target" for the
next and (to a lesser extent) next-next releases, used to identify
the bugs that need to be fixed when the reports come in versus lower-
priority ones that patches can be accepted for but little if any
actual developer time should be put toward.
On Feb 27, 2007, at 10:57 AM, Andreas Raab wrote:
> This looks pretty good as a working doc. The one thing that won't
> work out is the release schedule with the way releases are
> currently dragging their feet - which is noone's fault in
> particular but we can't deny that obviously this takes more time
> than anyone expects so we should acknowledge that and put up more
> reasonable target dates. Given the amount of time it takes to test
> and fix all that stuff a 6 months schedule seems better aligned
> with reality.
> - Andreas
> David Faught wrote:
>> You are hereby invited to please review and comment on the
>> Distributions and Testing Working Group page on the Consortium's wiki
>> at http://croquetconsortium.org/index.php/
>> Distributions_and_Testing_Working_Group This is a working document
>> and has not been totally agreed on by the team.
>> Kyle wrote:
>> Honestly, a new release should be available every few rotations of
>> planet regardless. "Release Early, Release Often" -- have the stable
>> SDK release, then the betas leading up to the next stable release,
>> instructions for "staying on the bleeding edge" from the
>> Also, release instructions on "update from one major version of the
>> SDK to the next".