Conversation
|
Is the signature change a breaking change? |
|
The move to v5 is breaking, as some other libraries rely on v4 and haven't been updated - we wouldn't be able to update without effort. Should there be a google-cloud-kit v1 that uses jwt-kit v4, and a v2 that uses v5? |
|
The signature change is most definitely breaking. Judging that the package is already in an RC state, it makes sense to tag a 1.0 that uses v4 and then a v2 that uses v5 as @owainhunt says (and also take the opportunity to migrate it to Swift Concurrency) |
|
I'll have a look on that, that's a great idea, I'll make the tags and everything. |
|
@nathanfallet let me know if you need this updated :) Or if there's other plans first |
|
I would say it's probably worth keeping this open to track the JWTKit changes until a stable release is tagged |
|
Understand the desire as above to wait until a stable release is tagged before moving this forward, though was curious if this branch, as is, works for others? Adding it to my project gets a compiler error on this payload. |
|
We're planning to tag the release this week and the API should be stable now so worth updating ready for that |
|
@0xTim I see there was an RC tag in august. Can we cut a v2 branch for google-cloud-kit to then adopt jwt-kit v5? Or what would you like to see here ideally? |
JaapWijnen
force-pushed
the
update-jwt-kit-version
branch
from
a28b4e9 to
e8cdcf3
Compare
|
@JaapWijnen If you want to do it under a major version then yep that's the way to go |
JaapWijnen
force-pushed
the
update-jwt-kit-version
branch
from
e8cdcf3 to
93b8d7a
Compare
|
Hey folks, any plans to move forward with this PR? 🙂 |
|
Just updated it to compile, tests pass locally. I'll let people merge and tag this when ready |
|
@nathanfallet @Andrewangeta is this waiting on anything before it can be merged/tagged? |
5 participants
This updates google-cloud-kit to use the new v5 version of jwt-kit. Currently a beta tag.
The new release contains some API improvements and no longer vendors BoringSSL!