Closed michaelholtermann closed 11 months ago
hey buddy,
me too 😅file name changes, additional platforms and changes to the underlying build system for travelling ruby in order to move from Ruby 2.4 to 3.2.2
hopefully nothing should break but even with all the testing in the world, we won’t truly know until it’s in the hands of the users.
i assume you are using the non beta v1 version of pact go?
Hi @YOU54F,
yeah, you are right, of course it's impossible to know all implications beforehand, so please excuse me if my question implied that :-)
Your comment implies that there is no breaking change you are aware of, e.g. some changes to the CLI, which is totally fine, IMHO.
I'm a believer of SemVer and a bit nervous if the major version of some dependency increases. Yes, we are on pact-go v1.7.0
, so I guess I should stay with pact-ruby-standalone v1.x
?
I can run some tests with pact-go v2-beta
if it helps, though.
I'm not sure pact-go v2 beta uses the standalone, although it might do for broker related functionality, if it does help testing is always appreciated
I think with the jump from ruby 2.4 to 3.2.2 and the build system changes for macOS users, which previously used the x86_64 package under rosetta, and for windows users who now have both the 32 and 64 bit versions, it is warranted.
I'd like to honour semver rules, and thought I was doing a decent there with the major bump
It seems linux users (debian based at least) will need libyaml-dev
from testing, otherwise they will see this error
libyaml-0.so.2: cannot open shared object file: No such file or directory -
/tmp/cirrus-ci-build/standalone/linux-arm64-2.0.0/pact/lib/ruby/lib/ruby/3.2.0/aarch64-linux/psych.so
https://github.com/pact-foundation/pact-js-core/pull/445
It will be something that probably wants fixing in the packaging system (traveling ruby) but for now that seems to do the trick 👍🏾
Not all ruby gems packed in pact-ruby-standalone, are ruby 3.2 compatible, oddly this either hasn't shown up across several test suites and test, but appears to be reproducible in some circumstances
ERROR ThreadError: can't be called from trap context\n\t/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/ruby/3.2.0/timeout.rb:184:in `synchronize'
( I think this is the lot, pact-stub-service comes in the verifier)
Hello! Is there any timeline on reverting the homebrew package? I've run into this error today and wondering if I need to revert to installing manually if homebrew's going to be out-of-action for a while.
Hello! Is there any timeline on reverting the homebrew package? I've run into this error today and wondering if I need to revert to installing manually if homebrew's going to be out-of-action for a while.
howdy! done @gregtyler. see above PR. you might need to untap/tap it rather than a brew update pact-ruby-standalone but see how you go
Awesome, thanks so much Yousaf! 🌮
Hey @gregtyler
Just to let you know I am have released a new version of homebrew-pact-ruby-standalone
if you have any issues, you’ll be able to stick with the v1.x branch with the following command
https://github.com/pact-foundation/homebrew-pact-ruby-standalone#previous-versions
2.0.3 seems pretty stable, we've had no more reports.
TL;DR - Breaking changes are the dropping of linux 32-bit and file name changes to the release artefacts (which might affect users scripts)
Thanks for raising @michaelholtermann - am going to close this one off now
Sorry for bothering, but I wonder if there is any breaking change between 1.92.0 and 2.0.0, beside the file names of the release artifacts?
We are developing pact tests in Go, which are executed during CI and rely on
pact-ruby-standalone
(https://docs.pact.io/implementation_guides/go/readme#installation), so I assume the update won't break our tests or tool chain, but I'd like to be sure.Thanks a lot!