New release cycle, an invitation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

New release cycle, an invitation

David Faught
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.

Dave

Kyle wrote:
Honestly, a new release should be available every few rotations of the
planet regardless.  "Release Early, Release Often" -- have the stable
SDK release, then the betas leading up to the next stable release, and
instructions for "staying on the bleeding edge" from the repositories.
Also, release instructions on "update from one major version of the
SDK to the next".
Reply | Threaded
Open this post in threaded view
|

Re: New release cycle, an invitation

Andreas.Raab
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.

Cheers,
   - 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.
>
> Dave
>
> Kyle wrote:
> Honestly, a new release should be available every few rotations of the
> planet regardless.  "Release Early, Release Often" -- have the stable
> SDK release, then the betas leading up to the next stable release, and
> instructions for "staying on the bleeding edge" from the repositories.
> Also, release instructions on "update from one major version of the
> SDK to the next".
>
Reply | Threaded
Open this post in threaded view
|

Re: New release cycle, an invitation

David Faught
The 3 month cycle was proposed by someone else, and this page just expands on
it a little.  I was wondering what might have prompted the desire for that
short of a cycle.  The only thing that occurs to me is that it would cut down
on any discrepancies that might come up in applying the actual updates,
allowing more people to be more up to date.  On the other hand, it could make
things more difficult for long term application projects, as they would
possibly have to update their projects more often to keep up.  Bigger, less
frequent changes or smaller more frequent changes?

Besides the 3 month release cycle, there are a couple more arbitrary timing
things in this page that may need more realistic targets.  Namely the building
of the beta archive 1 month before the release and the potential rebuilding of
secondary beta archives no more than once a week.  These were just thrown out
there to have a point to start with.
Reply | Threaded
Open this post in threaded view
|

Re: New release cycle, an invitation

Kyle Hamilton
In reply to this post by Andreas.Raab
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.

-Kyle H

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.
>
> Cheers,
>   - 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.
>> Dave
>> Kyle wrote:
>> Honestly, a new release should be available every few rotations of  
>> the
>> planet regardless.  "Release Early, Release Often" -- have the stable
>> SDK release, then the betas leading up to the next stable release,  
>> and
>> instructions for "staying on the bleeding edge" from the  
>> repositories.
>> Also, release instructions on "update from one major version of the
>> SDK to the next".