search

pact-foundation / pact-js-cli

The Broker CLI for Pact, but available to your node scripts
MIT License
1 stars 1 forks source link

Feat/arm64 binaries #1

Closed YOU54F closed 1 year ago

YOU54F commented 1 year ago

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.

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 commented 1 year ago

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 commented 1 year ago

can we do stuff like - 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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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