Prepare for v2.8.0 release

[milosgajdos]

This PR contains release notes and version bump for 2.8.0 release.
This will be the last v2.x release -- no future development should be expected on v2.x branch; all focus will be on getting a v3 release out next year.

The reasons why we've decided to go with v2.8.0 release rather than with a patch release (v2.7.2) as originally intended in #3380 is that #3384 technically introduces a new feature that warrants a minor release.

[codecov-commenter]

Codecov Report

Merging #3552 (d5d89a4) into release/2.8 (3b7b534) will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff              @@
##           release/2.8    #3552   +/-   ##
============================================
  Coverage        58.72%   58.72%           
============================================
  Files              102      102           
  Lines             7104     7104           
============================================
  Hits              4172     4172           
  Misses            2286     2286           
  Partials           646      646           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3b7b534...d5d89a4. Read the comment docs.

[deleteriousEffect]

@milosgajdos looks pretty good to me, I left a couple of little changes.

[milosgajdos]

Funny, applying these suggestion commits lead to failed DCO 😬 will fix manually...sadness

[deleteriousEffect]

@milosgajdos good stuff, thanks for all your work on the release. I know the community will appreciate it ☺️

[thaJeztah]

LGTM; going through the milestone, I saw #3134 was still pending, but not sure if a decision was made on that one yet (IIRC, it removes / updates some dependencies that were marked as having vulnerabilities).

[milosgajdos]

I somehow thought we had agreed on not including it in the release. We could I guess send some time getting some testing in place but I'm worried that will put the release off even further. Do we know how many people are using it off the 2.7 branch?

[thaJeztah]

Do we know how many people are using it off the 2.7 branch?

Don't know. If I understood correctly, the current implementation may even be broken, so if that's the case, I would not expect many (so happy to say "meh" and don't take it for now)

[milosgajdos]

I'm not against this, btw, but I'd need to find some time to look into that if we want to include it in the 2.8 release. Otherwise, if people scream, we can do another TOTALLY_LAST_2.X release later on, but I doubt anyone uses it.

[thaJeztah]

yeah, let's go with what we have currently

LGTM

[milosgajdos]

@distribution/maintainers can we get a review on #3315? Once that's merged in we're free to proceed with 2.8 release + we get an awful lot of other benefits from #3315

[thaJeztah]

Once that's merged in we're free to proceed with 2.8 release + we get an awful lot of other benefits from #3315

That one is for the main branch, so would have to be back ported to the release/2.8 release branch, correct?

[milosgajdos]

That one is for the main branch, so would have to be back ported to the release/2.8 release branch, correct?

We actually opted to handle building the images, etc. under main. Maybe we can massage it a bit and split that logic between branches but release/2.x will hopefully become dead wood soon. CC: @crazy-max

[thaJeztah]

We actually opted to handle building the images, etc. under main. Maybe we can massage it a bit and split that logic between branches but release/2.x will hopefully become dead wood soon. CC: @crazy-max

That feels "risky"; so build-scripts, Dockerfiles, and (e.g.) Go versions from the main branch will be used to build/release <some other branch>?

[milosgajdos]

Yeah, I'm talking to @crazy-max about it now. We'll address this soon

[crazy-max]

That feels "risky"; so build-scripts, Dockerfiles, and (e.g.) Go versions from the main branch will be used to build/release <some other branch>?

Nothing will be triggered on release/* branches atm because the build.yml workflow is not available there.

[thaJeztah]

^^ so there was some confusion, but if we want to use the new release workflow for the 2.8 release, it's indeed needed to have those (or similar) change in the release/2.8 branch; @crazy-max opened a PR to backport those changes; #3565

[darend]

@milosgajdos is there a process for suggesting fixes to be backported into future 2.8 betas? PR #3097 from 2020 updates the AWS SDK to fix compatibility with AWS IRSA which many are waiting on. It would be unfortunate to wait on a major release to get a bump to a very old SDK

[milosgajdos]

We might consider it if there is enough noise @darend.

[thaJeztah]

It's a large diff though, so should be looked at closely

[stevenolen]

We might consider it if there is enough noise @darend.

is there a location best to make this noise? AWS IRSA appears to have become the default way to provide aws credentials to pods in EKS, and given that kiam (another common method) is no longer being actively supported the other offerings in this space are dwindling/being replaced.

[milosgajdos]

@stevenolen mind opening an issue?

[stevenolen]

I actually got here from: #3275 which is still open. would you like a separate ticket?

[milosgajdos]

I can't promise anything, but I'll try to see into this. If you fancy opening a PR though, that would make things easier for us

[stevenolen]

Thanks @milosgajdos!

I'd be more than happy to help assist in whatever way I can! Having said that, I'm not entirely sure what PR to open 😄. It looks like the change we need is already on the main/master branch, merged by #3118.

Opening a PR to release/2.8 or attempting to cherry pick that commit don't appear to be super fruitful, given how different the go module file states have changed.

[thaJeztah]

I think we should look closely if it's safe to take for a v2.x patch release; the issue that it resolves (#3097) existed for quite some time, and the patch from #3118 brings quite a significant number of code (35k); there's always a risk involved in doing so.

Perhaps it would be worth starting with v3.0.0 alpha/beta releases (which would be released from main, so would have the change included)

[stevenolen]

I'm definitely a novice as it relates to this project/repository, but I think this would be OK for my team.

I'm making the (admittedly, perhaps naive) assumption that v3 wouldn't break serving/storing of existing registry content and the most core of registry APIs...given that you'd be starting from the current state of main, that's probably the case?

[milosgajdos]

I'd wager what's on main which is the branch that will be the base of v3 release is WAY more up to date and more efficient than what's on 2.8. I agree with @thaJeztah, getting some RC going soon is the best way going forward. For the time being, I'd encourage you to maybe start "test-running" the edge tag in https://hub.docker.com/repository/docker/distribution/distribution.