[wp-hackers] 120-day release cycle

[Michael Gall]

This can be mostly sorted by branching before the beta release, making it so
big changes can still go in on the trunk, and only bugfix releases are
applied to the branch, that will probably work on the trunk as well.

Michael

On 10/3/06, Alex King <lists at alexking.org> wrote:
>
> The only problem I see here is how big new features and new features
> from external developers get integrated. As it is supposed to work
> now, they exist as patches in Trac. If they sit for (potentially) 2
> months, it is likely that the patch will no longer fit. This puts the
> onus on outside devs to maintain/submit new patches through the 2
> month "polish and fix" part of the cycle.
>
> I can also see potential for features to be dropped from a release
> somewhat indefinitely because of timeline. Coordinating large new
> features is a good reason for creating branches, which can merged
> back even several releases later when they are ready for "polish and
> test".
>
> I'm not saying this is a bad idea - everything has trade-offs. I just
> thought I'd bring these points up.
>
> Cheers,
> --Alex
>
> Personal   http://alexking.org
> Business   http://kingdesign.net
>
>
>
>
> On Oct 1, 2006, at 11:48 PM:
>
> > 2 months of crazy fun wild development where anything goes
> > 1 month of polishing things a little bit, and performance
> > Feature freeze.
> > 1 month of testing, with a public beta release at the beginning
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>