[wp-hackers] 120-day release cycle

[Mark Jaquith]

On Oct 2, 2006, at 1:00 AM, Lloyd D Budd wrote:

> I look forward to seeing the impact of a fixed length development
> schedule and six months is what quite a few projects use.

120 / 30 = 4

;-)

> I think as an experiment after 2.1, we should aim to do a release  
> exactly 120 days after when 2.1 comes out.

I like it.

> 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

suggested addenda:

- Extra-long wp-meetup session around week 2, to discuss proposed  
goals for the next version
- Put these goals up on Codex, but stress that they are not set in stone
- Weekly reviews of these goals, during the first two months (during  
wp-meetup).
- If, at the end of the two months, some of these goals are not yet  
implemented, we should push them off to the next version, and at that  
point we can release a list of major features that'll definitely  
appear in the next version (two months away, at this point).
- At feature freeze, we should document any API changes, or changes  
in best practices (i.e. deprecated functions or methods of  
accomplishing something).  This will give plugin authors one month to  
upgrade their plugins.

Reasons for those suggestions:

- plugin authors complaining that changes are not explained clearly,  
and that they don't have enough time to prepare, or don't even know  
when to start
- users/developers complaining about lack of milestones
- users/developers complaining about features that didn't make it

--
Mark Jaquith
http://txfx.net/