Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prepare for v2.8.0 release #3552

Merged
merged 3 commits into from Jan 21, 2022

Conversation

milosgajdos
Copy link
Member

@milosgajdos milosgajdos commented Dec 21, 2021

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.

Signed-off-by: Milos Gajdos <milosthegajdos@gmail.com>
@codecov-commenter
Copy link

codecov-commenter commented Dec 21, 2021

Codecov Report

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

Impacted file tree graph

@@             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.

@milosgajdos milosgajdos requested a review from waynr Dec 21, 2021
Copy link
Collaborator

@deleteriousEffect deleteriousEffect left a comment

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

releases/v2.8.0.toml Outdated Show resolved Hide resolved
releases/v2.8.0.toml Outdated Show resolved Hide resolved
@milosgajdos
Copy link
Member Author

milosgajdos commented Dec 22, 2021

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

Signed-off-by: Milos Gajdos <milosthegajdos@gmail.com>
Copy link
Collaborator

@deleteriousEffect deleteriousEffect left a comment

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

@thaJeztah
Copy link
Member

thaJeztah commented Jan 5, 2022

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
Copy link
Member Author

milosgajdos commented Jan 5, 2022

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
Copy link
Member

thaJeztah commented Jan 5, 2022

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
Copy link
Member Author

milosgajdos commented Jan 5, 2022

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.

Copy link
Member

@thaJeztah thaJeztah left a comment

yeah, let's go with what we have currently

LGTM

@milosgajdos
Copy link
Member Author

milosgajdos commented Jan 11, 2022

@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
Copy link
Member

thaJeztah commented Jan 12, 2022

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
Copy link
Member Author

milosgajdos commented Jan 12, 2022

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
Copy link
Member

thaJeztah commented Jan 12, 2022

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
Copy link
Member Author

milosgajdos commented Jan 12, 2022

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

@crazy-max
Copy link
Contributor

crazy-max commented Jan 12, 2022

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
Copy link
Member

thaJeztah commented Jan 12, 2022

^^ 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

Signed-off-by: Milos Gajdos <milosthegajdos@gmail.com>
@milosgajdos milosgajdos merged commit 212b38e into distribution:release/2.8 Jan 21, 2022
3 checks passed
@darend
Copy link

darend commented Jan 21, 2022

@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 milosgajdos deleted the v2.8.0-release branch Jan 21, 2022
@milosgajdos
Copy link
Member Author

milosgajdos commented Jan 21, 2022

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

@thaJeztah
Copy link
Member

thaJeztah commented Jan 21, 2022

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

@stevenolen
Copy link

stevenolen commented Feb 22, 2022

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
Copy link
Member Author

milosgajdos commented Feb 22, 2022

@stevenolen mind opening an issue?

@stevenolen
Copy link

stevenolen commented Feb 22, 2022

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

@milosgajdos
Copy link
Member Author

milosgajdos commented Feb 22, 2022

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
Copy link

stevenolen commented Feb 23, 2022

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
Copy link
Member

thaJeztah commented Feb 23, 2022

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
Copy link

stevenolen commented Feb 23, 2022

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
Copy link
Member Author

milosgajdos commented Feb 23, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants