In my regular web wanderings this morning, I found something interesting. A company that I'm familiar with just released v3.0 of their primary product. At first glance, I was happy for them, then I remembered something odd, they released v1.0 early this year. By all standards, going from v1.0 to v3.0 in under a year is aggressive… so I started to dig and found something interesting:
V1.0 was released in February…
v2.0 was released in July…
v3.0 was released in December…
with no point releases in between.
Wha?
That's right, they had three major releases in a 10 month span with no minor releases in the interim… which poses an interesting question about using their system:
What is compatible with what?
As software versioning notes, a version number normally consists of three parts:
Major.Minor.Build.Release
Release – The Release (optional) is unique to each and every release. This can just be a sequential id for each release but is more often a Subversion Revision number (always increasing). That makes it easy to track that release back to a specific state of the code.
Build – The Build is normally a simple counter that increments until the next Minor release. This is used to denote bug fixes and potentially optimizations. You can see this on the PHP5.2 line. We have version 5.2[.0] (zeros are often left off), 5.2.1, 5.2.2, and we're on 5.2.8 preparing for 5.3[.0] right now. More importantly, backwards compatibility is maintained. Anything that works on 5.2.1 should work equally well on 5.2.4 or 5.2.8.
Minor – The Minor version is works similarly but not quite the same. It's normally a simple counter but instead of just fixing bugs, it adds new functionality. You can once again see this on the PHP5 line. We have the upcoming 5.3 release that includes all kinds of nifty new things like closures, lambdas, PHAR, Namespaces, and all kinds of nifty bits. The downside of getting new features is that sometimes things break. Backwards compatibility is strongly encouraged and worked towards but not guaranteed.
Major – Releases of Major versions are a whole other story. Not only are there bug fixes and new features, but there could be whole new re-workings of the core system and any backwards compatibility is an unexpected feature, not a guarantee. The PH4/5 conversionis one example, but the Office 2000/20003 to Office 2007 conversion is an even clearer. Files created with Office 2007 aren't backwards compatible with Office 2003.
Now let's get back on point…
When an organization – commercial or otherwise – skips over Build/Minor releases and sticks to Major releases, they may think they're showing how stable and active their community is… but they're actually doing the opposite:
They're creating a community that has to question whether their modifications and extensions.
They're creating a community that is always playing catch up in terms of documentation and understanding.
They're not giving any guidance for future versions and slowly stepping into them, they're simply rushing ahead full steam.
And most disturbingly, their users can't have confidence that their data will convert across and work without issue.