The tyranny of version numbers

Managing a software project around version numbers holds back prompt releases of new features. To paraphrase a Hollywood pirate, they’re more like guidelines, anyway.

I’ve been fortunate (read: stubborn enough) to have been contributing code to BuddyPress since around late 2009. In those early days of the project, the time between releases has fluctuated significantly. Version 1.2 to 1.5 took more than a year(!), and since then, we’ve achieved around 3 releases a year. We’ve learnt that sticking to self-set deadlines helps us manage a good cadence.

More recently, I think we’ve become comfortable with moving entire not-quite-ready features to later releases — not because we demand perfection from the first version of features, but because getting a release out on time has proven to be more valuable to the project. My inner project manager rejoices at such things, but as a developer, I don’t want to have to wait another couple of months before my contribution is made available to our audience. As a project leader, I worry about the impact these perceived timeframes might have on potential new contributors.

Since the popularity of mobile phone apps exploded in 2008, and for our community, since 2013 when WordPress 3.7 introduced auto-updates, version numbers have began to be a piece of jargon that only developers are interested in, not their audience. Can you tell me what the version number of the Twitter app on your phone is, without looking?

I think by the end of the decade, you won’t find any version numbers on any of the software on your computer. You won’t be using WordPress 5.6, you’ll just be using “WordPress”. The cost of auto-updating software is trust, but the benefits are always having secure software, and by being surprised by delightful new features on a regular basis.

The importance of the platform in auto-updates is not to be underestimated. Aside from mobile apps, desktop operating systems and video games are other examples of kinds of software that benefit from having platforms that deliver updates. WordPress plugins are very fortunate to have the delivery and update mechanisms that WordPress has (this is a tricky task to build well, and I have huge respect for all who make contributions to WordPress in this area). Apart from forced security updates, WordPress isn’t taking full advantage of its platform.

How can BuddyPress get itself ready for an inevitable future WordPress where plugin updates are delivered and installed automatically?

No matter how software updates are delivered, we obviously still need to write, test, and package new releases. BuddyPress often spends 3-4 weeks in beta and release candidate phases, and while the number of people using BuddyPress has grown significantly overtime, the number of humans who volunteer their time to help test our releases has not grown proportionally. We have been able to increase the number of robots, however.

The BuddyPress core team has an inside joke that if we have a release with four numbers in its version (e.g. x.x.x.y), it means we’ve embarrassingly missed a feature regression during testing, and are rushing out a fix! If you look at the BuddyPress release history, you’ll see this occurred somewhat frequently during the 1.2.x versions. The most successful step we’ve taken to try to stop such things reoccurring is to adopt unit testing, and have tests be mandatory for any new features.

However, testing in isolation doesn’t give me full confidence that the whole will work together. For that, I believe BuddyPress needs to adopt new testing techniques, such as Behat. Behat lets you create integration and acceptance tests by writing human-readable sentences that describe a feature of your application and how it should work. Pantheon have a great write-up explaining how Behat can be used with WordPress.

The other preparation BuddyPress must make is to automate the packaging of the release. Currently, this is a fiddly and frustrating 25-step process. My friend Boone Gorges made a start on a script to do this last year, and we need to finish it this year.

Once all these pieces are in place, the sky’s the limit. The project could push a release once a month, or once a week, or even after every commit. And what version number would those releases have?

Who’d care.