When we re-launched EDD Bookings a few weeks back, we did so at version 0.1.
This might not be the norm in the WordPress space as most plugin developers and owners tend to release at 1.0. There may be reasons for doing so, be it for development, marketing or anything else. In fact, WordPress itself has a version numbering system that even the Codex writers themselves admit is weird. Here’s a look at why we opted for a more structured approach.
We chose to follow SemVer (Semantic Versioning) – a widely adopted standard for versioning that advocates the use of version numbers that have real meaning. In short, every number of a version reflects how that version is different from the one that came before it. This system was authored by Tom Preston-Werner, inventor of Gravatars and cofounder of GitHub.
Every version has three numbers: a major, minor and a patch number. Although sometimes the patch number is omitted when it is zero, as is the case with 0.1 and 1.0. The versions 0.1.0 and 1.0.0 are respectively equivalent. Here’s what each of these numbers means:
- The patch number indicates how many times the product has undergone maintenance changes.
- These include bug fixes, minor text or style changes, and so on.
- The minor number indicates the number of times the product has had features and significant improvements added to it.
- These include new features, significant UI updates, and other similar changes.
- The major version indicates how many times the product has undergone major API changes.
- In layman’s terms, how many times the product has broken backwards compatibility. This is usually due to a rewrite. or massive refactoring.
We built EDD Bookings from scratch, rather than refactor the previous version. Therefore, we’ve essentially built a new product that has, so far, not undergone any API changes that broke backwards compatibility.
For this reason, and because we adhere to SemVer, the current major version of our product is zero. On the other hand, we’ve created a product that is being released with an initial set of features, so the minor version should be
Therefore, we’re starting our versioning at 0.1 and not at 1.0. SemVer also states that between 0.1, 0.2, 0.3 and so on, the product is allowed to break backwards incompatibility until it has matured and reached a point of stability. At that point, the product may be versioned as 1.0 to signify that it has reached its first stable version.
While we aren’t planning to break backwards compatibility between the minor versions that lead up to 1.0, if the need arises we will be providing measures and tools to ensure that any existing data on our users’ websites is kept intact. The same would apply for major version updates unless there is a specific reason not to.
What are your thoughts on SemVer? Do you prefer any other solution for versioning?