Go’s Major Versioning Sucks – From a Fanboy

Go's Major Versioning Sucks

The post Go’s Major Versioning Sucks – From a Fanboy first appeared on Qvault.

I’m normally a fan of the rigidity within the Go toolchain. In fact, we use Go on the front and backend at Qvault. It’s wonderful to have standardized formatting, vetting, and testing across the entire language. The first real criticism I’ve had is with the way Go modules handle major versions. It’s over-the-top opinionated and slows down development in a significant number of scenarios.

Refresher on “Go Mod”

Go modules, and the associated commands go mod and go get can be thought of as Go’s equivalents to NPM and Yarn. The Go toolchain provides a way to manage dependencies and lock the versions that a collection of code depends on.

One of the most common operations is to update a dependency in an existing module. For example:

# update all dependencies
go get -u ./...

# add missing and remove unused dependencies
go mod tidy

# save all dependency code in the project's "vendor" folder
go mod vendor

Semantic Versioning

Go modules use git tags and semantic versioning to keep track of the versions of dependencies that are compatible with the module in question. Semantic versioning is a way to format version numbers and it looks like this: v{MAJOR}.{MINOR}.{PATCH}. For example, v1.2.3.

Each number is to be incremented according to the following standards:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.

What’s the Problem?

When new versions of dependencies are released we have a simple command to get the newest stuff: go get -u. The problem is that this command has no way to automatically update to a new major version. It will only download new minor changes and patches. There isn’t even a console message to inform you that a new major version exists!

That said, the reason for not auto-updating is clear, and to be fair, well-founded:

If an old package and a new package have the same import path, the new package must be backwards compatible with the old package.

Import compatibility rule

In other words, we should only increment major versions when making breaking changes, and if breaking changes are made we shouldn’t be downloading them without knowing exactly what we are doing. Seems logical.

I Want Semantic Versioning, but Go Slows Me Down

It is often the case that I want to build a package that has domain-specific logic and will only be used in services at the small company I work for. For example, we have a repo that holds the struct{} definitions for common entities used across our system.

Occasionally we need to make backward-incompatible changes to those struct definitions. If it were an open-source library we wouldn’t make changes so often, but because it’s internal and we are aware of all the dependencies, we change the names of fields and keep things updated with business logic. This means major version changes are a fairly regular occurrence.

The problem is that Go makes updating major versions so cumbersome that in the majority of cases, we have opted to just increment minor versions when we should increment major versions. We want to follow the proper versioning scheme, we just don’t want to add unnecessary steps to our dev process.

How Is It Cumbersome?

On the Go Blog, the answer is laid out via an example:

To start development on v2 of github.com/googleapis/gax-go, we’ll create a new v2/ directory and copy our package into it.

In other words, for every major version, we are encouraged to maintain a new copy of the entire codebase. On the client side of the API we have even more inconveniences:

Users who wanted to use v2 had to change their package imports and module requirements to github.com/googleapis/gax-go/v2.

In other words, instead of a few simple CLI commands to get the latest dependencies, we also have to grep through the codebase and update all of our import paths.

Hey – I Get It

I understand why these decisions were made – and I even think in a lot of cases they were great decisions. For any open-source or public facing module this makes great sense. The Go toolchain is enforcing strict rules that encourage good API design.

In their effort to make public APIs great, they made it unnecessarily hard to have good “local” package design.

What I Wish Was the Case

If I could have it my way, I would only change a couple things:

  • Major versions on the package side should just use git tags like minor and patch versions. None of this copying the entire codebase nonsense.
  • Major versions should not be specified in the import path, just in the go.mod and go.lock files.
  • When running an update command like go get -u , there should be a prompt to ask “do you want to fetch major version updates?”

Barring this, at the very least can we add a warning to go get that at least informs us that there is a new major version? That would be nice.

Go still has the best toolchain and ecosystem. NPM and PIP can suck it.

If you disagree, @ me on Twitter.

Thanks For Reading!

Follow us on Twitter @q_vault if you have any questions or comments

Take some coding courses on our new platform

Subscribe to our Newsletter for more programming articles



source https://qvault.io/2020/09/15/gos-major-version-handling-sucks-from-a-fanboy/

Comments

Post a Comment

Popular posts from this blog

Why is Exclusive Or (XOR) Important in Cryptography?

Image
If you are getting into cryptography, or just trying to understand the fundamentals, you may have noticed that the exclusive-or operation is used quite often, especially in ciphers. What is XOR ( ⊕ )? XOR, or “exclusive or” operates on binary data. It returns true if both of its inputs are opposites (one false and one true), otherwise, it returns false. An example in go code would be something like: func exclusiveOr(a bool, b bool) bool { return a != b } XOR Cipher – The Perfect Cipher The XOR operation can be used as a simple cipher for encrypting and decrypting messages with a single key. This is known as symmetric encryption. It is interesting to note that if: The key is the same size as the message The key is kept secret and generated truly randomly Then the cipher is impossible to crack. This is known as a one time pad . However, a simple XOR shouldn’t be used in production due to the key length needing to be too long to be practical. Cipher Example A...
Read more

Base64 vs Base58 Encoding

Image
By Lane Wagner –  @wagslane  on Twitter Base64 is one of the most popular encoding formats for representing data. Have some binary data? Base64 encode it for convenient readability and parsing. Base58 is just another encoding format (with 58 characters instead of 64, and has gained popularity largely due to Bitcoin and other cryptocurrencies. When it comes to data encoding, there is typically a trade-off made between: Human Readability: Do humans have a good idea of what is being represented at a glance? Efficient data compression: How many bytes are used to represent the same data? Let’s rank Base58, Base64, and ASCII encoding against each other using these metrics! First: A Note on Binary All data is stored in a raw binary format on computers. These encoding formats (Base64, Base58, and ASCII) are just different ways of reading and writing binary data. For example, in Base64 the binary code 000000 represents the letter A , but in ASCII the binary 00000000 repres...
Read more

(Very) Basic Intro to Hash Functions (SHA-256, MD-5, etc)

Image
This is going to be a basic introduction to hash functions. I will assume most of my audience is here to gain an understanding of why hash functions are used and the basic idea of why they work. My goal is to explain it in a general sense, I will be omitting proofs and implementation details and instead focusing on the high-level principles. Why Use A Hash Function? Hash functions are used all over the internet in order to securely store passwords, find duplicate records, quickly store and retrieve data, and more. For example,  Qvault  uses hashes to extend master passwords into private encryption keys. A longer list of uses here:  https://en.wikipedia.org/wiki/Hash_function#Uses I want to focus on several important features of hash functions, arguably the most important features. Hash functions scramble data deterministically No matter the input, the output of a hash function always has the same size The original data can not be retrieved from the scrambled d...
Read more