@manusa: Do you have any insights on this?

This seems kinda risky, no?

@manusa: Do you have any insights on this?

I do have a recent experience about a complaint from a JKube user regarding something related.

eclipse-jkube/jkube#2697

Starting from v1.16, we switched to use standard/recommended Kubernetes labels as opposed to those that JKube (formerly Fabric8 Maven Plugin) prescribed.

When the user upgraded to the newer JKube version with the changes, their pipelines failed due to the existent Deployment selector containing different values.

We did recommend the recreate approach (where the previous Deployment is deleted and then reapplied), but this was not possible for them. See eclipse-jkube/jkube#2697 (comment)

@iocanel if having version in label makes impossible to update deployments shouldn't this not be avoided?

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 070107b.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

@iocanel if having version in label makes impossible to update deployments shouldn't this not be avoided?

Adding the version to the selector has it's pros and cons. If we just remove it then users will only be able to correlate pods by name, which can be problematic as users won't be able to route traffic between version etc. Things like canary, a/b testing it will become trickier.

So, we need give users the option to decide how they'll roll.
Currently, it's enabled by default. We could possibly change that but that means that it will then bite everyone once.

Something additional that worth mentioning ... This behavior (having the version being part of the label) is inherited by dekorate since 2019. Meaning that its not something that we just recently change. The main reason why this is has been just discovered is the transition from DeploymentConfig to Deployment which is the resource affected by it.

I suggest we move forward with this pull request. And move to an optional opt-in strategy for the next major release.

@gsmet @yrodiere wdyt ? seems like good first step to inform users what to do early.

I suggest we in anohter PR make add-version-to-label-selectors be false by default. That will still cause exception on existing deployments that has label but with this PR its now informative/helpful, and any future quarkus versions wil allow rolling deployments by default.