We have been versioning products for ages. Some products use a basic numbering scheme starting at one and incrementing the changes. Other products, such as cars, use the year to indicate a version. A version is “A particular form of something differing in certain respects from an earlier form or other forms of the same type of thing.”
This post will review some schemas and how they can help you keep track of your artifacts.
Why We Version
In DevOps, we use versioning to ensure that the artifacts we are deploying are identifiable with known and ideally tested functionality. If we always deployed the latest artifact, that could very well be an alpha or beta build that could have bugs or incompatibilities.
Versioning Schemas
Now that you have some background information established, let’s discuss the most common versioning schemas.
Name-Based Versioning
Versioning with names is one of the most fun schemas; however, it’s also the hardest to understand. With name-based versioning, you assign random names to each version. Usually, naming ties to an internal version number. Android has used it—remember KitKat, Lollipop, and Nougat? Apple does it—Mountain Lion, Yosemite, and Ventura. Next time you have an application to redesign, give the project a fun name.
|
Pros |
Cons |
|---|---|
|
Major versions and new projects can have a fun name to build team pride |
No direct correlation between the versions |
|
|
It only works for Major versions |
Semantic Versioning
I’m going to say this right here. If you provide the software for others, then Semantic versioning should be your choice. Everyone should be familiar with Semantic Versioning, or Semver, as it’s sometimes called.
Semantic Versioning uses the familiar MAJOR.MINOR.PATCH versioning, such as 1.2.3. Generally speaking, a patch release has backward-compatible bug fixes. Minor releases have new or updated features that are backward-compatible. Major releases have breaking changes.
SemVer works well when you publish software for others to download and use. Users can see if they have the latest version and if the upgrade will have breaking changes. The challenge is that it requires a user to define the version, especially when we move to Major and Minor versions.
One of the common variations is to replace the PATCH level with a build number or to append the build number at the end, such as MAJOR.MINOR.PATCH-BUILD. This ensures that you can identify the different builds of the same patch.
|
Pros |
Cons |
|---|---|
|
Widely used |
Some issues trying to update the version in pipelines. |
|
Can see the scope of the change, for example, if there were just patches, or things were changed |
Discussions around if the change is a patch or minor version. |
|
|
In-house projects may never get a version 2, so part of the version number never is updated. |
Calendar Versioning
Calendar Versioning, or CalVer, is my go-to choice in my pipelines. Calver uses the date to create a version number. A build number or even an incrementing patch number may also be used to ensure that a unique version is created. Since CalVer has no single defined standard, it allows you to customize the version number. For example, YYMMDD.<BuildNum> may result in a version such as 220710.345.
A benefit of CalVer from an automation perspective is that you can quickly generate a unique version programmatically as part of the CI process. You can quickly determine the artifact’s age with the date as part of the version. With the date and build number, you can quickly find the build and the source code, providing traceability.
|
Pros |
Cons |
|---|---|
|
Unique version generated at build time |
Not compatible with some libraries, such as NPM |
|
Each version is guaranteed to be newer than the last |
|
|
Great for projects where we don’t have a defined version, such as in-house projects |
|
Additional Considerations for Versioning
While we’ve gone over the pros and cons of the most popular versioning schemas, there are some additional considerations for more specific use cases.
Internal Version Number vs. Release Version
Nowhere is it written that you can’t have 2 version numbers. For instance, you may have an internal version number, where you keep track of the build that happens several times a day, and a Release version where you apply the unique version to the object. You can use automation to create the unique version numbers during the development process, and then create the semantic version at release.
Docker Tags
If you are publishing Docker containers for others to use, you’ll frequently have multiple tags for the same image. You’ll have a latest tag for the latest image in addition to a version tag. If you are using semantic versioning, consider creating the following tags which will allow some updates to happen if an updated container is pulled. For example, your customer uses the tag MAJOR.MINOR, then when that tag gets updated due to a patch, then the next pull will get the update.
-
MAJOR.MINOR.PATCH - Created as part of a new patch
-
MAJOR.MINOR - A specific minor version that is updated with new patches. This can be used when we want to allow patches to auto-update.
-
MAJOR - Same as above, but is updated with minor versions also. Used to only stay with the Major version.
-
Latest - The latest version, includes
Conclusion
In the end, the best schema will be one that provides the needed information to the software consumer with as little possible decoding required.
I like CalVer for my daily builds that are only used for Development. I can quickly determine the age of the artifacts and purge old builds. As a plus, CalVer works great with automation, as I don’t need to read the version and make any updates. I also like Calver for internal applications where we don’t really care about the version.
If you’re publishing software for others, such as a software library, then SemVer is king. You can tell how far behind you are on releases, and if the latest release will have any impact, or break things.
You can also just create your own schema with your own rules for your organization. And don’t forget to name your next website redesign Project Puppy Pup.
Need Help?
Bitovi has DevOps consultants who can help. Drop into Bitovi’s Community Slack, and talk to us in the #devops channel or book a free consultation for one-on-one assistance!
Previous Post
