search

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: Release stackable-operator 0.69.0 #800

Closed Techassi closed 1 month ago

Techassi commented 1 month ago

Release stackable-operator 0.68.1 which includes these changes:

Techassi commented 1 month ago

I wouldn't classify adding labels to PVCs a breaking change. If it is breaking, it should've been marked as such in the original PR (#799).

sbernauer commented 1 month ago

It was missed in the PR and I wasn't quick enough to review :)

I would use something like

- BREAKING: Add labels to listener volume builder. `PodBuilder::add_listener_volume_by_listener_class`, `PodBuilder::add_listener_volume_by_listener_name` and `ListenerOperatorVolumeSourceBuilder::new` now require you to pass the labels for the created volumes ([#799]).
Techassi commented 1 month ago

Ah well, another instance where manually maintaining the changelog file caused an issue. I guess we consider the changes as breaking because we altered the API. It shouldn't be breaking from a functionality point-of-view.

I will adjust the changelog and the version.

It might be worth to differentiate between these two instances. Should we open a decision / discussion for that?

sbernauer commented 1 month ago

Ah well, another instance where manually maintaining the changelog file caused an issue.

The label changelog/breaking was also missing, I don't see how automation could have prevented that :see_no_evil: Maybe there is a tool out there that automatically detects breaking changes, but that might be an overkill for our small lib with mostly only us as users.

Should we open decision / discussion for that?

Would be great, but I'm personally happy as is, given our limited time resources. For me it's important to state why this change is breaking, than users can decide on there own if they care or not

Techassi commented 1 month ago

I don't see how automation could have prevented that

Using conventional commits could solve that. It uses ! to indicate when a change is breaking. That obviously would require that developers don't forget to use it :)

Maybe there is a tool out there that automatically detects breaking changes

There actually is, see https://github.com/obi1kenobi/cargo-semver-checks

Would be great

Alright, I will create one in the next couple of days.