Shipping a new open source project? Have you thought about release naming?

I came across this recently while working on the GitHub Release Radar. We ask people to submit projects that have shipped major versions. We look at projects with x.0 releases in a particular month. For example. 1.0, 2.0, 3.0 etc.

However, I've come across a few projects who don't seem to use this versioning system for their releases. I did some research and came across a few different types of software versioning systems.

Here's an overview of them.

Semantic versioning

Software projects use semantic versioning, which consists of three different components:

X.Y.Z or MAJOR.MINOR.PATCH

So when we talk about major version releases for the Release Radar, we are talking about "major" software ships. Minor changes are updates to the main version that add functionality in a backwards compatible manner, according to 4Geeks. It can also include minor added features. A patch is a backwards compatible bug fix.

We look at major versions for the Release Radar as we want to highlight breaking changes and new features, as opposed to backward compatibility or bug fixes.

Within these three components, people can use different types of formatting within semantic versioning:

Semantic Version by number

The versioning I talked about above that uses 1.0, 2.0, 3.0 etc. releases, is called semantic versioning by number. When we look at the Release Radar we want to look at the version and ensure it's using x.0.0.

Semantic versioning by number is probably the most common type of version naming.

When it comes to choosing projects to feature in the Release Radar, we look for major releases. For example, if you have 4.2.9, this would indicate version 4.0, with a second minor update, and the 9th bug fix to version to 4.0. We'd want to wait until 5.0 is released so we can highlight new features.

Semantic Version by stability

Instead of using numbers, software projects might be known as alpha or beta before they are officially released. This is known as versioning by stability.

For the Release Radar, we usually wait until an official version is shipped before showcasing a project. We want to ensure it's stable enough for all people to use before promoting the product or service.

Semantic Version by date

This is one that's got me a couple of times. This is when companies use the year or month to indicate the version. "Office 2013" for example is the major version released in 2013.

Some open source projects might use 21.10, meaning the 10th month, of the year 2021. This can help if you're shipping updates every month or you simply want your users to know exactly when the software was published.

Example: Home Assistant uses semantic versioning by date. This release for example, 2021.12 is December 2021.

Public version

A public version is something that, instead of being known as 3.0, or similar, is known by a specific name or number. For example. "Windows 10" isn't Windows 10.0. Instead, it is just known to the public as Windows 10. It could very well be the 10th version of Windows, but this isn't how it's promoted or showcased. A better example is "Office 365", "iPhone 5S" or even "Samsung Galaxy Watch 3".

Yes, they missed Samsung Galaxy Watch 2, and therefore rather than following semantic versioning, Samsung is following public versioning here. Other open source projects might even call their releases by affectionate names, such as Android Honeycomb, Ice cream sandwich, Lollipop etc. Whilst these might correspond to semantic versions, they are more commonly known by their names.

Note how a software release can have BOTH semantic version by number, and public versioning.

What version are you using?

So there's a little bit on different types of versioning systems when it comes to naming software releases. What system are you using? Are there ones I've missed?

If you're using something different than version by number, and you're submitting to be featured in the GitHub Release Radar, please note that in your submission.