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". |
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". > |
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. |
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". |
Free forum by Nabble | Edit this page |