docs: update CHANGELOG.md for v3.5.11

[github-actions]

Automated changes by create-pull-request GitHub action

[agilgur5]

confusing commits

@Joibel I'm looking through some of the backported commits and some of them seem to have come out quite strangely:

• b6e591e is a backport of fix: constraint containerType outboundnode boundary. Fixes #12997 #13048 but contains no changes
  • EDIT: It looks like I backported this already in 9bd2c31... did you use a different script to calculate backports? It shouldn't be backported or in the CHANGELOG twice, which is very confusing to a user -- i.e. "so is this fix in 3.5.10 or in 3.5.11?" would be a good question
• EDIT: 8393080 is similar to above -- its changes are entirely different from the original PR fix(cli): argo lint with strict should report case-sensitive errors. Fixes #13006 #13250
  • I had similarly backported this before in fbc56d4, where I did notate that I fixed a merge conflict with the go.mod. My backport is identical to the original PR, whereas you seemed to have solely added the merge conflicts that arised from surrounding deps? Again not sure if you used a different script, but those changes are unrelated to the original PR and attributing them in that commit and in the CHANGELOG is confusing at best. Similarly backporting the same commit and having it the CHANGELOG twice is confusing as well
• be77948 is a backport of fix(api): deleteDelayDuration should be a string #13543, but it contains go.mod and go.sum changes that did not exist in the PR. It seems to be missing some other generated client changes as well.
  • The latter might be due to OpenAPI generator dep versions changing, the former I have no idea
• 1892cea is a backport of fix(build): slightly optimize UI tasks in kit tasks.yaml #13350 but contains extra changes
  • build: fix ARGO_LOG_LEVEL -> ARGO_LOGLEVEL #11978 wasn't backported, which is where those changes come from. Properly fixing that merge conflict would be to just backport that commit as well
    • going back and backporting more commits to fix merge conflicts properly was something I mentioned in Document & improve process for release rotation #12592 (comment). EDIT: added this to the docs in docs(contrib): add notes on handling merge conflicts during backports #13634 as well

There might be more, those are just ones I happened to check (mostly for milestone purposes, see below)

conventional practices

Some other notes:

• Per docs: Improve release instructions #11382, we don't typically backport ci, build, or chore changes like ci: test k8s version 1.28 and 1.30 #13381 etc
  • Just fixes and CVE dep upgrades, plus any commits those might require so as to not merge conflict. Plus docs updates due to versioned docs (Versioned documentation #11390) these days. I.e. as minimal as possible
  • Some build and dep changes also can result in breaking changes (like minimum k8s version when client-go is upgraded)
  • We can backport them, and it would reduce the diff, which is beneficial, but they tend to cause more conflicts than they're worth. Sometimes they're also breaking changes -- like the above PR means that older k8s versions are no longer tested on release-3.5
  • That's also why there's linter errors in the branch per 25bbb71, there's an entirely different linter on main (refactor(deps): migrate from deprecated tslint to eslint #12163)
• I try to explain any merge conflicts in the backport's commit message too, but I don't see any message in yours, so I'm not sure what's going on in them
  • I'll add that to the Releasing guide as best practice, that wasn't documented and was something only I started doing. EDIT: added in docs(contrib): add notes on handling merge conflicts during backports #13634
• Also I've mentioned this before on Slack, but if you're not sure how to resolve a merge conflict, it's best to just do the safer / less risky thing and leave the commit out
  • I can add that to the Releasing guide as well. EDIT: added in docs(contrib): add notes on handling merge conflicts during backports #13634
• Your cherry-picks are also missing the original commit reference, i.e. the -x flag that I added in fix(hack): various fixes & improvements to cherry-pick script #12714

additions I made

Things I added:

• I've been adding the "v3.5.x patches" milestone to any issues & PRs that didn't have it that made it into this release.
• I added backports of the CHANGELOG PRs to the release-3.5 branch as well, e.g. e83f3e7 and 7c4463e
  • these are very helpful for permalinks, as future tags will now contain the CHANGELOG modifications, so you can reference, e.g. v3.5.9 and see the CHANGELOG at that point in time and rely on that tag as a permalink
  • otherwise it's basically just another docs backport

rest

Most of the changes look good though! Seems like we fortunately did not have that many dep changes in this release which often cause much of the complex conflicts

• Also nice catch with 3a05962, which fixed something that a prior backport erroneously added during a merge conflict in 02a3e2e (that line did not change in fix(build): check for env vars in all dirs #12652, but it would have merge conflicted)
  • In-line version references make those easier to catch too 😉

[agilgur5]

Also codegen is failing on the release-3.5 branch, potentially due to how #13455 was backported in b881cf0 ?

[agilgur5]

#13446 (comment) was also missing from 3.5.11, possibly others

[agilgur5]

Also codegen is failing on the release-3.5 branch, potentially due to how #13455 was backported in b881cf0 ?

#13446 (comment) was also missing from 3.5.11, possibly others

For reference, neither of these were resolved in 3.5.12 (#13841) despite my multiple requests here and on Slack and the assurances those received 😕

It is past out of my hands now