Calendar Versioning Works

I have been working on several size projects. One of those projects, related to the Christmas Light Show called Falcon Pi Twitter, has custom built software that runs it.

When a question gets asked about how my show is set up, I share the details about the electrical aspect of it and the Twitter application that posts the song data. When they hear about the Twitter account and how it works to post the information about the current song, questions roll in.

I realize that this could be a valuable opportunity to make this application into a full, open source application that can be used by other individuals that use the Falcon Pi Player as part of their light show. One aspect of creating software is that you have to do releases and with releases, are release numbers. There are many release number strategies, but I wanted to share the one that I chose and why I chose it.

Semantic Versioning

From what I have been able to find, there are multiple ways of doing semantic versioning. There’s the

major.minor.build

major.minor.patch

major.minor

and the list goes on. With this pattern, only one of the numbers change when there is a release and the number that changes depends on what was done as part of that release. This in my opinion was a bit more than what I was looking to have with my application because thought to know what was changed, cannot be easily scripted to update the version number, and can make your application look outdated although it just had a release.

Calendar Versioning

This strategy names the version number based on the date that the release was built or make available. Like the Semantic Versioning, there are variations of this versioning as well. They are

year.month

year.month.date

year.month.patch

This pattern has multiple strategies. Most common with this strategy is that there is one feature release per month or per day, and bugs fix releases are done between feature releases of they are severe enough. This pattern is also easy to come up with the release number as you only have to pull the current date. You know how old the latest release is because the year and month that it was released is in the version number.

My Choice: Calendar Versioning

I decided to go with calendar versioning because it is easy to set up with scripts and does not require that you have to know whether a bug or feature was added to the application.

The pattern that I decided to go with is

year.month.date

It is highly unlikely that I would do multiple releases within the same day, but is possible that I do multiple within the same month with new features and bug fixes.

It Looks Like Semantic Version Number

The only problem with this is that it looks like Semantic Versioning with the 3-digit version number. From what I have seen, as part of the application's documentation, the version number scheme is sometimes included, especially if it is following a "year.month" or similar strategy. The difference in my opinion is that most can tell that it is a calendar versioning because the first digit of the pattern is usually a year, not a single- or double-digit number. One exception to this is Ubuntu's versioning method. They use the 2-digit year as the first number instead of the 4-digit year. I'll be using a four-digit year as part of my versioning pattern.

Breaking Changes

A point that is made by those who create software is that calendar versioning does not help developers that are not working on the application know when there are breaking changes or features added. In my opinion, this is true. Knowing what features have been added or bugs have been fixed is part of the release notes. Version numbers do help with finding that information fast, but ultimately as a developer, one should be reviewing the release note and application documentation to see what has changed and how to update their code regarding the new changes.