[wp-hackers] 120-day release cycle
lists at alexking.org
Tue Oct 3 15:00:41 GMT 2006
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).
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.
> 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
>> 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
More information about the wp-hackers