How do you decide version numbering for your theme/plugin updates?


(Leland Fiegel) #1

Up until now, I’ve went with a super informal system. I wasn’t really sure if there were any more structured systems for it, so I just guessed.

I’d start with 0.1 if it’s a really preliminary beta version. I’d up to 1.0.0 for the first “stable” version. Then I’d just add a “tenth” for each new version. So 1.1.0, 1.2.0, 1.3.0, etc. Once I got to 1.9.0, I’d just up it to 2.0.0, kind of like WordPress does. The first number doesn’t have much significance like other software projects.

For example, WordPress 4.0 was not radically different from WordPress 3.9.

But I just discovered something called Semantic Versioning which makes a lot of sense.

Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards-compatible manner, and
  3. PATCH version when you make backwards-compatible bug fixes.

So I think I’ll go with that from now on. Do you use any sort of structured system like this, or did you have more of an informal system like what I did before?


(Ben) #2

I always used to do what you do (did) just adding 0.1 to each version - but now I use a basically follow the semantic versioning system.

I always start my version at 2. This is because there can be themes with the same name in the wordpress.org repository (I try to avoid it but they can be released after my theme is released), and this can conflict with the auto updates (at least it did before I added my own auto update system) - so by starting at 2 I generally start a version higher than the wordpress.org version. A few themes I had to bump to version 10 because of .org conflicts :frowning:

I try to make major versions backwards compatible. I tend to reserve this for major rewrites.

I actually only started taking versioning seriously a year or two ago and now detail all the versions, and the dates the changes were made, in the themes readme.txt.

I also make all my changelogs public - so people can see I do maintain my themes - https://prothemedesign.com/tools/changelogs/


(Denis B) #3

I didn’t know about the semantic versioning but I use something quite similar. I start from 1.0.0 then 1.0.1, 1.0.2…1.1.0 , If I have a major update like entire code refactoring or additional features then I’ll jump to 2.0.0, 3.0.0 etc .
Since all my themes are on wordpress.org it doesn’t matter what my versioning number system is as long as it’s incremental .


(Leland Fiegel) #4

Interesting! Never thought of that.

There’s also a code-based way of disabling update checks that I found from @devinsays on WP Theming. The same post also talks about high version numbers as another way, but the code seems like more of a surefire method.

Makes sense. :slight_smile:


(Mark Senff) #5

I’ve always gone with the MAJOR.MINOR.PATCH rule, meaning that if there is a minor update after 3.9, it would be 3.10, not 4.0.

But, having said that, in general, I think version numbering has been messed up for a while, ever since Firefox/Chrome started releasing new versions of their browser every few weeks.


(Primoz Cigler) #6

I’ve followed semantic versioning since I can remember. It’s super easy, consistent and you can tell right away what kind of changes are introduced just by checking the log.


(Anh Tran) #7

I always use semantic versioning. However, I see some disadvantages from that:

Not always we do a major update. Major update is considered as a big change like architecture change (for example WooCommerce 3.0) that probably can’t handle backward compatibility. This situation rarely happens with themes, but with plugins, because themes structure are mostly stable, plugins are not. In most of time we do minor update, such as adding more features or fixing bugs (bug-fixing-version-only will be patch). That will cause the MINOR number increases quite fast for a large plugin (mine is 4.11 now).


(Leland Fiegel) #8

Yeah, I was thinking this too. I can plausibly go through many minor updates without ever needing to make a architectural change that would warrant a major update version bump. So a theme could be on 1.x.x for years if I followed SemVer to the letter.

I also find it kind of confusing that 4.11 is a newer version than 4.5, even though 4.5 is mathematically a greater number, for example. I think I still might do what WordPress does and do a “major” number bump after 9 “minor” versions to avoid that.

But at this point, I haven’t released enough minor updates on anything to worry about it yet. :smiley:

Haha, yeah. I have no idea what version numbering system they use. I’m using Chrome version 58.0.3029.81 (64-bit) at the time of this posting. :smiley: