19:10 Semantic Versioning

This is the main type of versioning you’ll need to know, as it is by far the most common. Version numbers are four segments, usually themselves numeric.

The segments each mean something. Major – A change here is a breaking change. A previous or next major version is unlikely to work with something that needs the current version. Minor – Changes have occurred, but are unlikely to break something. This might be a fix for something like a non-breaking security change. Revision/Patch – Changes have occurred, but almost certainly don’t break things. This might be something like a fix for wording or a spelling error. Build – Indicates a particular build. Probably not useful for anyone but the developers. This is often left off the version released to the public.

The idea here is to communicate a number of things regarding version compatibility and risk for anyone using the library or application and to do so in a standardized way. Be aware that clients often interpret these version numbers incorrectly. Sometimes you run into situations where multiple things need to have the same version number, but change at different rates

30:30 Other Versioning Structures

Semantic versioning comes from a world before continuous delivery. Sometimes the first two sections in the version number will have components of the date. For example 2018.3.11.92 would be the build for either March (or third quarter) of 2018, revision 11, build 92. You can pretty much use whichever portion of the date you want for this. Be aware that this can inform clients just how long it has been since the last version, which may not be what you want.

Some software packages just use a single version number that increments with each release. This makes it easier on users, at the expense of development and support. You can also show two different version numbers, with the more detailed one being hidden in an “About” screen somewhere. This also means that you probably should release fairly frequently, rather than relying on interim patching.

34:15 Producer Side

When incrementing a version segment number, zero out all the segments following it. Version only the main branch in source control. This would be the branch you release to clients. Trying to keep versions sane across multiple branches is liable to get ugly fast.

If you know that you are shipping breaking changes, then increment the major version number. If you are making big changes, but they don’t break backward compatibility, then increment the minor version number. If you are just fixing a bug and it doesn’t break backward compatibility, then increment the revision number. The build number should increment when the continuous integration server builds

44:35 Consumer Side

Read the release notes. Don’t update for a while after an update comes out. Give other people time to get burned. Obviously the above doesn’t apply if there are major security issues.

When you are consuming a library and the major version has been incremented don’t update this directly in the development branch. Instead, make a branch and update there then fix all the stuff that got broken. Then merge back into development.

When a library undergoes a minor version update, you are probably safe updating in a development branch. Just make sure you can roll back. The big consideration here is the likelihood of this sending you down a rabbit hole trying to fix it. If a particular library or framework has burned you on a previous update, treat their minor revisions like a major one.

“Trust, but verify.”

When a library has a revision change, you should be safe updating on your development branch, with some caveats. This is no time to skip reading the release notes. A little update that someone else asserts “doesn’t have breaking changes” may have subtle changes that will break your stuff. When a library makes a build update, ignore it.

There is one other thing to consider, especially if you are using a package manager due to security concerns. Be very careful about updates, especially ones that haven’t been out a while. If the publisher of a package gets breached, they could end up publishing a package that does nefarious things. This is not foolproof, however. You should also be checking release notes, running under minimum privileges, etc.