docs: add v0.5.0 release CHANGELOG entry

[shaneutt]

What type of PR is this?

/kind documentation

What this PR does / why we need it:

This is required to release v0.5.0.

Which issue(s) this PR fixes:

Fixes #1183

Does this PR introduce a user-facing change?:

NONE

NOTES

This was a very manual process that relied on the git history as well as Github PR history. It wouldn't be too surprising if I managed to miss some things. We should probably revisit how we manage this in the future to avoid having to do this.

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[robscott]

Thanks @shaneutt! This is a really great list. I have some ideas around how to structure this changelog, but the content looks right to me.

[robscott]

Adding a hold for consensus + we usually try to make the changelog commit the very last thing we merge before publishing a release.

/hold

[shaneutt]

First @robscott I wanted to point out that I took some of your suggestions, but I did vary some from what you suggested originally. Please take another pass and see if what I have now seems agreeable.

Also on this point:

Adding a hold for consensus + we usually try to make the changelog commit the very last thing we merge before publishing a release.

I actually would like to ask that we don't hold this PR, and instead merge it now so the remaining PR's can themselves be responsible for adding CHANGELOG.md entries. I made a proposal in #1193 aimed at making updating the CHANGELOG.md a consistent thing over time between all contributors so that we don't have to take a long time to compile a list right before release. Please let me know your thoughts and please review that PR.

[robscott]

Some more suggestions for recategorization, but based on one of your comments you may already have some of this done and just not pushed.

[robscott]

Maybe clarify that these are changes that will only affect implementations that rely on the Go types. Most users of Gateway API will be unaffected. I'm a little hesitant to include these because it could set a precedent for always including Go type changes, something that is not done in upstream Kubernetes. Maybe we can add a caveat that this covers the major changes but may not be an exhaustive list?

[shaneutt]

I've changed the language and added the note you requested in 226a034. Let me know your thoughts.

[robscott]

I think we may need 2 sections here - one to talk about release channels (and likely link to https://gateway-api.sigs.k8s.io/concepts/versioning/), and the other to talk about new features. I think the only new features in this release are parentRef.port and path redirects and rewrites.

[shaneutt]

It's not super clear to me what exact action you want taken here, but I did move the reference to 1002 (parentRef.Port) into this section now as that seemed to be something you were getting at. Done in 226a034. Let me know your thoughts.

[youngnick]

I think that we need a summary of the release channels at the top, so we can call out which things are in which channel. We probably also need to call out that conformance testing will only work on the experimental channel for now, pardon our dust, etc.

[shaneutt]

Release channels header now added in 0b7da46 👍

[youngnick]

This is looking awesome, I made some suggestions for talking about release channels though.

[youngnick]

I think that we need a summary of the release channels at the top, so we can call out which things are in which channel. We probably also need to call out that conformance testing will only work on the experimental channel for now, pardon our dust, etc.

[robscott]

Thanks @shaneutt! Will plan on merging this in tomorrow as last step before release. Always appreciate more reviews on big PRs like this, but LGTM.

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: robscott, shaneutt

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [robscott]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[youngnick]

/lgtm

[robscott]

/hold cancel