Release cycle of Wordpress

During an interesting discussion regarding suggestions on how to improve WordPress core development on the WordPress hackers mailing list, Ryan Boren who is one of the core contributors with committ access laid out the foundation as to what the team tries to accomplish with each release of WordPress. I thought it would be good to bring this into more of the open for those wondering what’s involved.

** Alpha **

* Collect feature ideas from ideas forum, support forums, most popular plugins, dev brainstorms, and other sources.
* #wordpress-dev meetup to decide on which features we want to commit to and set the scope of the release
* While this is going on, do some trac gardening of things that got punted from the previous release. We’re pretty bad about this sometimes, but with 3.0 Peter and I have been going through some of the backlog.
* With features decided, create “task” tickets for all features targeted for the release. Set existing “enhancement” tickets that made the cut to “task”. Start developing and submitting patches to the tickets.
* At the same time, more trac gardening on existing tickets.
* Continuous integration in trunk, committing feature work early and often. Trunk may break at times, but we’re all dogfooding the latest bits.

** Feature Freeze **

* Once all features are deemed complete via meeting on #wordpress-dev, we enter feature freeze. Sometimes we have features that aren’t quite ready that are noted as exceptions to the freeze. Everything else is put in feature freeze with the hope of driving to beta on everything else. Ideally, there would be no freeze exceptions.
* Drive to remove all beta “blocker” bugs in prep for entering the beta cycle

** Beta **

* “blocker” tickets are cleared. Beta 1 is released to kick off the public beta cycle.
* Fix bugs and start punting enhancements.
* Release Beta 2 about a week later.
* Fix bugs and start punting less severe tickets.
* Release Beta 3 a week later.
* Punt everything but blockers and fix those blockers.

** RC **

* Release RC1
* Wait x days. In the past this has been from 1 day to a week or so.
* If more bugs, release RC2. (We haven’t done this in awhile).

** Final Release **

* Release it
* Monitor feedback and start collecting fixes for a maintenance release.

** Alpha **

Dion Hulse also had a good list of ideas. If you have any thoughts or ideas on how to improve core development, place them here in the comments.

From: Weblog Tools Collection

Related posts:

1. Meeting minutes Wordpress Development Meeting on #wordpress-dev Wordpress announced their Meeting minutes of the meeting on Wordpress...
2. Participate in the WordPress 24-Hour Has-Patch Marathon! WordPress is organizing a Has-Patch marathon, be sure to participate...
3. Wordpress 2.9.1 is out! After over a million downloads of WordPress 2.9 and lots...
4. Wordpress open source plans for 2010 2010 is the year we dive into open source design....
5. 5 Cool Wordpress plugins everybody should use! I see alot of discussion on the web concerning which...

Related posts brought to you by Yet Another Related Posts Plugin.