Some time in the middle of last week, the forthcoming Confluence 1.5 release was quietly renamed Confluence 2.0. The reaction on the forums was as one would expect:
bq. And uh, so much for v1.5, eh?
Atlassian products use a traditional three-digit “major version, minor version, patch level” version numbering system. Whenever we release a new Confluence version that consists only of bug-fixes and backwards-compatible improvements, we increment the third digit. Whenever we release a significant milestone that adds new features and may not be entirely backwards-compatible, we increment the second digit.
But that’s only two digits out of three. The first is a bit of a problem. What really constitutes a big enough change to justify increasing it? Intuitively speaking, you have to overhaul a lot of the application to make that jump.
Some products never do. Sun, for example, will occasionally decide that a product is never going to change enough to justify increasing that first digit, and will remove it entirely: thus Solaris 2.6 was succeeded by Solaris 7, and the next step after J2SE 1.4 was Java 5. Many open source products, in contrast, spend their whole lives trying to reach some mythical version 1.0.
Some products abandon version numbers entirely and name themselves after the year of their release (not really an option when you’ve released five major upgrades in two years). Others adopt arbitrary names, which is fine if you have enough marketing presence to make sure consumers know that, say, Vista comes after XP, or Tiger beats Panther. Or in Confluence’s case, that Swan begat Nymboida, begat Murrumbidgee, begat Yarra.
So what inspired the progression from Confluence 1.4 to 2.0? The glib answer, of course, is marketing. And like most glib answers it’s both mostly correct, and entirely unhelpful.
Back when we were preparing Confluence 1.4 for release, I put a pretty strong case to The Powers That Be that we should call it 2.0. 1.4 had a lot of new features. More importantly to my programmer brain, a lot of the internals of the system had been rewritten, including the wiki to html renderer, the plugin API, and the user interface. The version bump was vetoed, however, because one big feature was still missing: WYSIWYG editing.
Come Confluence 2.0, we have another impressive list of features to announce (labels, dynamic RSS feeds, and of course WYSIWYG editing), but we can’t really say that it’s a significantly bigger jump than the change between 1.3 and 1.4. It’s more that the aggregate effect of both versions pushes us over the line. We have patched, replaced, rewritten, polished, enhanced and reupholstered most of Confluence since 1.0, we just never did it all in a single release.
In short, Confluence deserved some kind of recognition for how much it has advanced since its first release, what seems like a lifetime ago (well, March 2004). So in a week or so, it’s turning 2.0.

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now