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.
Add in a test phase between alpha and feature freeze.
Change criteria for release from “result of meeting” to “passes test”.
Good info Jeff!
> If you have any thoughts or ideas on how to improve core development, place them here in the comments.
Probably best to take the thoughts or ideas to the wp-hackers mailing list linked above.
I usually always suggest that option but the mailing list is not for everyone. I imagine for anyone reading this post that is a member of the mailing list and didn’t see this thread go by, they will be partaking in the mailing list side of the discussion. For everyone else, the comment form on this post should be adequate. I know multiple discussion points is no good but the mailing list is not everyone’s cup of tea.
Long time no talk by the way, Happy New Year.
Add features as plugins instead of core code, so that we can easily deactivate features we don’t need and be easier to separate code that may be causing bugs (all plugin developers ask first to disable all other plugins to see if any other one is the cause of the problem…).
Core should be focused on basic features, database access and secutiry. There should be official plugins that are API/Framework for some features, and then plugins that depend on these plugins and use their API to implement more advanced features and UI.
Not sure if you’ve looked into it but what you describe sounds a lot like the Canonical plugin idea that you’ll read and see more about this year.
Yes, I’ve read it and I’m happy they are going toward that line now 😀
It has been used in Drupal for a long time. Its core has almost no feature, only basic stuff, frontend structure, admin area, theme and module structure, only real essencial stuff. Then it comes with a dozen of modules that are supported by them, and there are modules that are only base API that does nothing alone and are used by many others.
Last time I read about Drupal they were planning to add part of CCK module in main distribution and support it officially, and CCK would remain only as a UI. That’s great because CCK is used by a lot of modules!!
In WordPress I’d like to see this kind of distribution as a permalink API where we could eaier develop plugins to customize them, API for managing tags and clouds, for cross-posts links, for menu generation, etc. Everything as plugins distibuted with WordPress and outside its core!
I18n string freeze! I also would like to see some kind of notification on the polyglots mailing list (or somewhere) before releases so we can be ready to make the locale packages.
Thanks for posting that. I don’t follow any of the WP mailing lists (although I probably should) so it’s nice to have some insight into the development process.