Why Our New Plugin Started at Version 0.1

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.

Semantic Versioning

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 co-founder of GitHub.

Here’s an explanation of how it works from Miguel, our current lead developer:

Every version has three numbers: a major, minor and a patch number. 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 since the last minor/major version. 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 since the last major version. 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 backward 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 backward 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 is one.

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 backward 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 backward 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 about the old EDD Bookings?

This is a short update added on 14/10/18 following a few valid comments made upon publishing the post on 12/10/18.

As some of you may know, EDD Bookings already existed before this version. For that reason, since publishing this post, I have received a few comments about why EDD Bookings is not at version 3.0. Here’s why.

EDD Bookings was previously developed by our team but sold and support by the EDD team. This changed in September 2017 when EDD stopped selling 3rd party extensions on their website. We took over the development, support, and sale of EDD Bookings. At this point, we decided to stop development on the EDD Bookings that was at version 2.2.5 and build something completely new.

When doing so, we kept the same plugin name, but that was it. That was the only thing that remained from the old EDD Bookings. The new version is a different package, both figuratively due to it being completely new in terms of code, and literally in that it’s a different repository and Composer package.

Yes, this new version is built upon the many, many important lessons learned from the old version. Yes, the product functions well. Yes, our users will get a lot of value out of it, even if the internal API is changing. That is why we chose to release the plugin before it reached version 1.0.

We do not intend to wait for backward-compatibility breaking changes to jump to version 1.0. In fact, we are allowing ourselves to break backward compatibility up until version 1.0, which is a version that indicates stability.

What are your thoughts on SemVer? Do you prefer any other solution for versioning?