WordPress 2.9.1 was released yesterday, after a relatively short beta and RC1 pair of cycles.
Some of you may recall the controversy surrounding WordPress 2.9, surrounding some defects that were discovered shortly after its release– although some people have mentioned that the problems, they felt, were present even in the previous versions of the software. As mentioned by Ryan at the WordPress development blog, those noticed defects were addressed by this release, as well as a few other minor issues selected to be included.
Operations Recommendations and Notes
Apparently, since the recent series of posts about WordPress 2.9 and the 2.9.1 beta came out, many of you have been sending E-mails and messages about providing more guidance to prod-ops teams and developers. The following recommendations should not be taken as gospel, since I strongly advocate sound development practices and practical management processes and more than a little common sense: rather, they should be considered in context with your current situation and deployment strategy.
Recommendation for Standard Operations Teams
At this time, the recommendation is that it is a worthwhile upgrade for most technically savvy production operations teams, as well as developers accustomed to using and manipulating WordPress. However, the customary testing procedure is strongly advised: download it, set it up in your testing environment and vet it through your test suite(s), prepare your CM machinery to handle the new version if it passes your tests, and deploy it to your production environment.
Recommendation for Agile Operations Teams
For the heavier types of agile development, if you have already cleared WordPress 2.9, you should be able to layer 2.9.1 on top of your previous iteration and restart your testing segment and merge back to your expected path. Once you have cleared it, you should be ready to deploy it to your staging/production environments.
For the aggro types, you probably have been tracking beta and RC1 versions of WordPress 2.9.1, but the latest changes for it should be considered as overriding the previous two changesets. If you are sweeper types, overlay 2.9.1 onto your outbound segment and restart testing. If you are satisfied with the results, you should be ready to deploy it to your staging/production environments.
Recommendation for Continuum Operations Teams
Yes, I know: this is somewhat redundant. But a couple of you have asked about continuum development recommendations, so here ’tis:
You most likely already know the outcome of your tests, but the question is in which order should your production environments be refreshed. The easy answer would be to use the exact order you have been using all along; however, some teams do have highly variable distribution orders, so the prevailing advice here would be to deploy into production prioritizing first in order of increasing code complexity and then in order of increasing network or traffic load. So your simpler outbound segments with lower traffic and integrations with other packages would be rolled out first, then you proceed upward in complexity and then frequency/traffic/load. For this version, avoid simultaneous or near-simultaneous rollouts unless your tests have already proven 0.00% disruption.
Hint: our tests showed ~4.33% disruption across all outbound segments, > 120.
N.B.
Other related Javamancy posts (in reverse chronological order):
- Stop the Insanity! Or, WordPress Development for 2010, a New Year’s Resolution
- Complaining About WordPress: Does That Make You a Bad Person?
- Uh-Oh: WordPress 2.9.1 Coming Soon?
- WordPress 2.9 Released
Other related Javamancy mini posts (in reverse chronological order):
