{"id":717,"date":"2020-06-02T16:04:04","date_gmt":"2020-06-02T15:04:04","guid":{"rendered":"https:\/\/marketaylor.synology.me\/?p=717"},"modified":"2020-06-04T09:44:29","modified_gmt":"2020-06-04T08:44:29","slug":"mq-go-package-version-modules","status":"publish","type":"post","link":"https:\/\/marketaylor.synology.me\/?p=717","title":{"rendered":"A “major” update to the MQ Go package version"},"content":{"rendered":"\n

The Go language and toolchain did not have a good version control system when created. Systems built on Go could not easily define the levels of the dependencies underpinning the system. Various tools were developed to help with that such as dep<\/code> and glide<\/code>. But more recently, the Go compiler environment has defined modules <\/strong>as the way forward. The MQ Go packages<\/a> are now available in a format that works with modules, with a major number version update to match. This post describes what has been done in the core MQ packages. <\/p>\n\n\n\n

A separate post<\/a> talks about changes in the mq-metric-samples<\/a> repository that exploits these packages and enables monitoring in tools like Prometheus and Influx.<\/p>\n\n\n\n\n\n\n\n

Modules<\/h2>\n\n\n\n

Many programing languages and tools support some kind of dependency management. If you are writing Java programs and using maven <\/strong>as a build tool, then the pom.xm<\/em>l file defines all your direct dependencies and their versions; if you are writing Node.js programs, then npm <\/strong>with package.json<\/em> fulfills a similar role. <\/p>\n\n\n\n

These dependency managers all have good and bad points. One aspect in particular that can be problematic is when two components declare dependencies on the same package, but at different versions. The decision of which version to use can be confusing, and there may be no guarantees that you end up with a working system.<\/p>\n\n\n\n

The design chosen for Go programs is known as modules<\/a>. Packages declare which version they are, and consumers of those packages say which version they want to use. In this environment, the MAJOR number associated with a package (for example, the “4” in “v4.1”) is especially important as it can help to simplify the multiple-version resolution. The semantic version<\/a> (semver<\/em>) rules are assumed and applied. Within a given major version, compatibility is a given – while new function can be added within that major version, nothing that already exists will be removed or changed. Breaking API changes can be made only with a new major number. That simplifies the options for picking which versions to use.<\/p>\n\n\n\n

Modules in the MQ Go interface<\/h3>\n\n\n\n

The mq-golang repository contains two packages: ibmmq <\/em>and mqmetric<\/em>. A single module can contain multiple packages and so these share the same version. The repository on GitHub had already gone through several incompatible changes as the APIs evolved, and had reached v4.1.4. I wrote an introduction to the API in its early days in this post<\/a>.<\/p>\n\n\n\n

One aspect of the Go module support is that it is relatively easy to add it for repositories that are still at v0 or v1. But once you get beyond that, migrating to modules essentially requires a new major version. And so there had to be a v5.0.0 release.<\/p>\n\n\n\n

There has been no real change to the ibmmq <\/em>APIs in this release but using modules means that references to it need to change. There were a few changes to the mqmetric <\/em>APIs used by monitoring programs. While I could have introduced those changes in a compatible way, I took advantage of knowing that there was a new major version.<\/p>\n\n\n\n

Application Programming with the MQ module<\/h3>\n\n\n\n

The changes to use modules in your applications are made in two places.<\/p>\n\n\n\n