We've moved!
This site is now read-only. You can find our new documentation site and support forum for posting questions here.
Be sure to read our welcome blog!

Version numbers

Geraldine_VdAuweraGeraldine_VdAuwera Cambridge, MAMember, Administrator, Broadie admin

GATK4 version numbers are based on semantic versioning. If that term doesn't sound familiar to you, rest assured it's just a fancy way of saying that the version numbers are structured in a meaningful way.

The official "semver" semantic versioning scheme describes a system of MAJOR.MINOR.PATCH version, where a MAJOR version bump involves breaking changes, a MINOR version bump adds functionality without breaking anything, and a PATCH version provides bug fixes (to existing functionality) that don't break anything.

In GATK4, we apply a relaxed interpretation of that scheme. We use a PATCH version for a release has only very minor changes, or bug fixes only, and a MINOR version for "typical" releases containing some new features and some bug fixes. We go to a MAJOR version on an exceptional basis, when we have major new features to show off.

So, how do GATK4 version numbers match up to this? The MAJOR.MINOR.PATCH version numbers are those that come after 4. So for example, version was the 12th minor version of the initial (0th) release of GATK4, and it has not received any patches. Now you may point out, waitafrigginminute, isn't the 4 itself a version number? Well, yes it is, but we decided it should be considered "bigger than MAJOR" so that we wouldn't already be jumping to GATK5 after, like, a year of development. We made such a big deal out of that 4, we want to keep it around for a while, y'know? So we kept it as a sort of prefix to the "proper" semver-compliant version.

There you go, fascinating bit of GATK4 trivia right there.

Sign In or Register to comment.