It’s that time again in the release cycle where we have to be bad guys to be good guys. We’re past deadline, we’re hitting the holidays, and if we don’t start cutting the cord, 3.3 will hang on until next year. Say it with me: Not again!
For the people working on the release, most of whom run trunk on their own sites for at least a month or two (if not longer) before each launch, it’s easy to forget that features we had done months ago — flyout menus, drag and drop uploading — are still being hoarded by us (and more recently by the lucky recipients of a merge onto wordpress.com) and are not available on the sites of regular users. While we try to take the time to examine every bug, every fix, and every report of one of those not working, all the stuff that is done and working fine is just sitting there, waiting on the sidelines to be asked to dance by a happy WordPress user who’s still not even at the party.
It’s time for everyone to join the 3.3 party.
From the WordPress.org Philosophy page:
Deadlines are not arbitrary, they’re a promise we make to ourselves and our users that helps us rein in the endless possibilities of things that could be a part of every release. We aspire to release three major versions a year because through trial and error we’ve found that to be a good balance between getting cool stuff in each release and but not too much that we end up breaking more than we add.
Good deadlines almost always make you trim something from a release. This is not a bad thing, it’s what they’re supposed to do.
The route of delaying a release for that one-more-feature is, literally, a rabbit hole. We did that for over a year once, and it wasn’t pleasant for anybody.
The more frequent and regular releases are, the less important it is for any particular feature to be in this release. If it doesn’t make it for this one, it’ll just be a few months before the next one. When releases become unpredictable or few and far between, there’s more pressure to try and squeeze in that one more thing because it’s going to be so long before the next one. Delay begets delay.
So, here’s where we stand: We’ve had some unexpected big bugs (widgets, etc). We’ve had some people get sick. We’ve had some people traveling. Or moving. Or having kids, a job, a family, a life. It happens. We are one week away from our target launch date, and we still need to do beta 4 and an RC cycle. Clearly we will be launching late.
As of today, we are a steamroller paving the way to 3.3 launch. There are 36 tickets right now. Of those, a few are still time-consuming blockers. Yes, those have to get fixed. If someone can’t write content, that’s a big problem. Pretty much everything else that still needs work will be moved to 3.4-early. Note that “has-patch” is not the same as “has-patch and has been agreed upon as a patch we should include in core.” Patches needing more work… need more work.
So instead of yelling, “How dare you punt my bug!” please instead focus on how important it is for us to get this release out, and the sooner we do, the sooner we can get back to all the things that got punted or postponed as we start the 3.4 cycle. Hey, we punted our pet projects that weren’t done in time too — language packs, some of the responsive admin stuff, pointers on the new-install tour, etc. No one was spared. (And believe me, I really wanted those pointers.)
So, countdown to 3.3 should start now. I’d offer a betting pool, but since we could totally rig it, that would be lame. If we can do beta 4 today, RC1 after the US Thanksgiving holiday, we could still release before the core team meetup in mid-Dec. We postponed a release until after the meetup last year, and I wish we hadn’t. So let’s just get this sucker out the door, yeah?
Shipping is a feature.
And remember, since you run trunk, you’ll get all that 3.4 goodness before you know it!
Jane Wells 3:42 pm on November 23, 2011 Permalink |
If it didn’t jump out at you, some help with the accessibility and RTL fixes would great, even if it’s just doing QA the fixes the core team has made.
Andrés Sanhueza 3:54 am on November 24, 2011 Permalink |
Will the 3.2.2 remaining tickets be considered?
Denis 12:41 am on November 25, 2011 Permalink |
Would it be possible to insist, over at onswipe, that they add a “never show this crappy theme” link on WP.com? And if not, would it be possible to disable the thing on this blog, if not on WP.com altogether by default?
I hate to be bursting on this blog in particular, but it’s the last WP.com I’m still following on my iPad… You guys (as in WP.com) have serious problems ahead if your goal is eye balls, and nonetheless stick with onswipe.
On a seperate note, there’s a severe bug when writing comments on iOS5 with a 1st gen iPad on this blog. I’ve no idea if it’s iPad or WP related but the comment box’ size toggles between 3 and 10 lines as I’m writing.
Jane Wells 1:20 pm on November 25, 2011 Permalink |
Surely the place for this report would be wp.com support, not the open source project’s core dev team blog. http://en.support.wordpress.com/contact/
John Blackbourn 12:08 pm on November 27, 2011 Permalink |
Of course this is not the place to discuss OnSwipe, but I wholeheartedly agree with Denis. OnSwipe is so unusable it beggars belief that it gets implemented anywhere, let alone on the entire WP.com network.
@Jane: Would it be possible to disable OnSwipe for iPad for this blog please? It’s under Appearance -> iPad.
Alex Mills 11:30 pm on November 27, 2011 Permalink
Done.