Feat/arm64 binaries

[YOU54F]

includes pact-ruby-standalone 2.x with arm64 macos/linux binaries.

32 bit windows binaries are no longer downloaded, and ia32 has been dropped from the package.cpu cpus field.

• we don't supply ffi binaries for win32 platforms and don't provide 32 bit linux or macos builds, so this would support an edge case for windows 32 bit users, who can't use any of the other node tooling (other than v9 pact-js or pact-node, which includes older 32 bit builds anyway)

node engines is increased to 16.x

GitHub Actions updated to test on 16, 18, 20 versions of node
Cirrus-CI added to test arm64 macos / linux

[YOU54F]

What should the version be when we release?

13.13.3 is the current?

can we do stuff like <package-version>-<standalone_version> similar to the Dockerhub tags for pact broker and pact cli.

They show

0.53.0-pactcli0.52.0

where

0.52.0 is the version of the pact cli bundle (as part of pact-ruby-cli)
0.53.0 is the docker related version, which may be bumped semver style based on Docker changes, not changes to the underlying ruby cli package

https://hub.docker.com/layers/pactfoundation/pact-cli/0.53.0-pactcli0.52.0/images/sha256-e49d6f3a1f47d53e874bae96e53ca9e04ca34bdd802016f6a653f0445b431fa0?context=explore

Notes on that versioning style (same in pact-broker-docker)

https://github.com/pact-foundation/pact-ruby-cli#versioning

[mefellows]

can we do stuff like -<standalone_version> similar to the Dockerhub tags for pact broker and pact cli.

It's an interesting idea. We'll probably want to version it independently of the CLI version (e.g. if the wrapper API or release has a bug in it).

We can't (or rather, shouldn't) use the - syntax, as that denotes a pre-release. The only reason the docker version has that is that it doesn't support the + for metadata.

So perhaps something like major.minor.patch+<ruby standalone version> ?

This way, the metadata shows what version is contained in the package, but isn't included in the precedence calculations.

[TimothyJones]

My 2c - yes, it’s definitely build metadata, so it should go after the + (if at all).

Secondly- what problem are you solving by having the version in the version number? Most users will want the latest (no matter what) and users who care will be able to read the release notes

[YOU54F]

we mention in several places to pin the version of the cli tools used in CI, so you get consistent behaviour.

we updated the pact-ruby-standalone script to reflect this, and its mentioned in the pact-go readme.

NOTE: the above script installs the latest standalone tools at the time it was ran. It is recommended you pin the installation to a specific version of a release so that you may control the upgrade cycle.

We've also stated in several issues that its not advisable to use latest and instead pin to a specific version.

If I am pinning to a specific version of the pact cli tools via the install scripts in pact-ruby-standalone, the pact cli docker, it might make sense to have that meta easily available to users consuming it via npm so an organisation can get consistent behaviour across the multiple pact-cli tooling entry points

You can tag packages in npm so maybe we could just do it that way. so there is always a tag pointing to the bundled version of the pact-ruby-standalone tools.

That is my basic rationale, our best practice advice of pinned versions for consistent results.

Outside of that, it was just a thought for consistency based on Beth's versioning changes performed in pact-broker-docker, the rationale behind that is below

https://github.com/pact-foundation/pact-ruby-cli#versioning

[YOU54F]

Will merge now and we can determine version number shortly and get an initial release out.