Test-drive the GATK tools and Best Practices pipelines on Terra
Check out this blog post to learn how you can get started with GATK and try out the pipelines in preconfigured workspaces (with a user-friendly interface!) without having to install anything.
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 188.8.131.52 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.