[wp-hackers] 120-day release cycle

[Alex King]

For internal development - yes. However WP has never (to my  
knowledge) used branching for this in the past. Doing so with this  
new release strategy makes sense, but there has to be a choice to use  
branches this way. So far, that part of the equation had not been  
part of the discussion (as far as I could tell from this thread).

Cheers,
--Alex

Personal   http://alexking.org
Business   http://kingdesign.net


On Oct 3, 2006, at 3:01 AM, Michael Gall wrote:

> 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".
>>
>>
>> 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