stackabletech / operator-rs

A simple wrapper/framework around kube-rs to make implementing Operators/Controllers easier

Apache License 2.0

112 stars 11 forks source link

chore: Bump Rust dependencies and GitHub Actions #782

Closed Techassi closed 2 months ago

Techassi commented 2 months ago

Description

Bumps Rust dependencies and GitHub Actions based on what Renovate reported.

Definition of Done Checklist

Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
Please make sure all these things are done and tick the boxes

# Reviewer
- [ ] Documentation added or updated
- [ ] Changelog updated
- [ ] Cargo.toml only contains references to git tags (not specific commits or branches)

NickLarsenNZ commented 2 months ago

Should we also bump to Rust 1.78.0 in this PR?

Techassi commented 2 months ago

LGTM, will you do the release and tagging in a separate PR, or update the changelogs to have the new release versions and tag once merged?

Yes. I just wanted to release stackable-operator and leave all other crates as is. Any objections?

Techassi commented 2 months ago

Should we also bump to Rust 1.78.0 in this PR?

Sure thing. I will bump it.

NickLarsenNZ commented 2 months ago

LGTM, will you do the release and tagging in a separate PR, or update the changelogs to have the new release versions and tag once merged?

Yes. I just wanted to release stackable-operator and leave all other crates as is. Any objections?

Since they all share the same workspace lock file, we probably need to release all?

Edit: I see, they will just be unreleased changes in the other crates. Which could only pose a problem if they are used together where there are conflicting types?

Techassi commented 2 months ago

LGTM, will you do the release and tagging in a separate PR, or update the changelogs to have the new release versions and tag once merged?

Yes. I just wanted to release stackable-operator and leave all other crates as is. Any objections?

Since they all share the same workspace lock file, we probably need to release all?

Edit: I see, they will just be unreleased changes in the other crates. Which could only pose a problem if they are used together where there are conflicting types?

Yeah, it is a hard topic to handle. @nightkr touched on this as well today. I guess we should have a discussion about that at some point in time.

For now, I can release all of them to avoid any conflicts.

nightkr commented 2 months ago

Monorepo with polyversioning: the simplicity and predictability of polyrepo and the flexibility of monorepo.. :P

Techassi commented 2 months ago

I think https://github.com/Byron/gitoxide might be a good repo to look at on how to handle versioning.

sbernauer commented 2 months ago

I'm a bit surprised that we released this as 0.67.1 instead of 0.68.0, as we do a minor (thus breaking change) bump of re-exports such as kube and k8s-openapi. E.g. an product-operator building a Volume or a PodSecurityContext itself will break.

No need to do anything and it will probably be fine, just wanted to make sure we are on the same page going forward :sweat_smile: And yes I'm being pessimistic here :D