ExpressionEngine Add-on Versioning
Versioning, as a software paradigm, is kind of a funny thing. For most customers, version numbers are a pointless sigil with as much meaning as acronyms and buzzwords like OOP, MVC, TDD, or what PHP stands for. For web developers though, and this includes you designers too, knowing what version numbers mean and how important they are to the right people is pretty important. Oddly though, no one ever really talks about this so I wanted to go into some of the ins and outs about versioning so we’re all on the same page.
Personally, I think it might surprise a lot of people to know that there is no set or official standard for how to version software projects and products. Seriously; if we wanted to, we developers could make it up as we go along and we’d, technically, be doing nothing wrong. We’d be weird and piss off the few people who care about this stuff, absolutely, but we also wouldn’t be in the wrong from a standards and practice sort of way.
In fact, take a look at some of the programs on your computer right now. Chances are you’ll see a variety of formats similar to Jeff Atwood when he talked about version numbers a few years ago:
Here’s a quick survey of version numbers for the software running on my machine at the moment:
17.0.6000.16386
8.1.0178.00
11.11
2.7.0.0
2.5.10 / build 6903
2.0 build 0930
0122.1848.2579.33475
2.0.50727.312
2.0.0.1
1.8.20061.20418
We’re allowed to do this because, for most customers of software, and especially those who aren’t developers, version numbers are straight up useless. It has absolutely no meaning for most of our clients whether they’re using Securit:ee 1.0.4 or Securit:ee 1.3.3. Hell, I’m lucky if the client even knows that they’re using Securit:ee at all so the version number really just doesn’t exist for them.
But to developers (specifically ExpressionEngine website and add-on developers) this means a great deal. When you’re putting together a site, the version number can literally mean the difference between things working like you’d expect, with up to date and accurate documentation, or having things go all weird, gross, and just plain wrong causing hours of wasted time and frustration.
For most ExpressionEngine add-ons, the basic convention we use is:
(Major).(Minor).(Patch)
So, for example, using Securit:ee again at version 1.0.4; 1 would be the Major version, 0 the Minor, and 4 the patch.
Now, the meaning of those numbers varies from dev to dev (again, because we can just make this stuff up). But, for me, the breakdown works something like the below.
Major is pretty meaningless until it changes. Honestly, Major version numbers are mostly marketing. There’s very little information to be gained there outside of when it changes. When the Major version changes it usually means your code for the previous version is gonna break. That’s all a Major version number tells you in my experience.
The Minor version means a great deal for my work. A minor version update is essentially a new thought or idea for the program. There are always new features and concepts and ways of doing things and even changes to the database structure. Traditionally, there are also lots of bug fixes and patches involved though that’s not always the case.
The Patch version is always a continuation of the Minor version. This can include fixing bugs that cropped up, cleaning up the new features (so they work easier/better), and even adding new features along the same concept as the Minor version. For example, the 1.3.1 branch of Securit:ee had some features to help finalize the idea of secure passwords and expiring stuff. New features => same concept.
Not all devs work in the way that I do though a great many do. Personally, I’ve found the above to be a very good mindset when looking at others products. Major increase means something broke or there’s a new design (or just marketing), Minor increase means bug fixes and new features, and Patch increase means bug fixes at the least.
Still, it’s far from ideal. There are a great many discrepancies involved and, as mentioned previously, there’s no set standard we’re following. To make this easier on ourselves I’d like to see ExpressionEngine add-on developers follow a proposal called Semantic Versioning. Semantic Versioning is a convention for version numbers that allows developers to get a good deal of insight at a glance and without much of a mental investment. I like that.
I don’t want to go into too much detail into Semantic Versioning because I think it’d be best for everyone to take a look and come to their own conclusions. I will say that I absolutely love the idea of documenting our code for use by other developers though. Please take a look at Semantic Versioning; I look forward to the discussion on this.
Lastly, I want to discuss the pre-release versions; the so-called “zero dot” release. The lack of understanding for the implications have hit me personally a number of times from various customers and users of my code (more in the WordPress ecosystem than ExpressionEngine) so I think some clarity is called for.
A zero dot release (for example 0.7 or 0.1) is not production ready. It’s usually short hand for Beta or even Alpha code. Using zero dot code, plugins, and/or programs in production is setting yourself up to pain. Lots and lots and lots of pain. It’s for advanced users only. You, seriously, have to know what you’re doing to use zero dot code in production. And, even then, it’s generally a bad idea.
For example, my WP-Click-Track WordPress plugin never reached a 1.0 release. I never felt it was ever “done”. It’s still, after all these years, only at 0.7.3 with no further updates planned. To any sane developer, using that plugin in production is just a bad idea. Still, the number of support requests from people who used it as a core part of their business is staggering.
Sadly, because it never went to official release there was very little support available (before I retired from WP). Now though, even with me being 100% done with WP and invested in ExpressionEngine I still get frantic emails from people about how it no longer works with the latest WP update or server environment.
These people are hosed and it’s just so sad. They did it to themselves by doing things they didn’t understand way above their experience.
So, to be blunt, don’t use zero dot releases in production unless you know what you’re doing.
Eric Lamb is the developer of professional and enterprise grade ExpressionEngine add-ons. Founded in 2009 Eric’s company mithra62 aims to be a leader in ExpressionEngine add-on development and has a reputation for stability, usefulness, and being highly configurable.