Skip to content

Move release-content content to _release-content#23638

Open
dylansechet wants to merge 1 commit intobevyengine:mainfrom
dylansechet:move_release_content
Open

Move release-content content to _release-content#23638
dylansechet wants to merge 1 commit intobevyengine:mainfrom
dylansechet:move_release_content

Conversation

@dylansechet
Copy link
Copy Markdown
Contributor

@dylansechet dylansechet commented Apr 3, 2026

A couple PRs got merged in still using release-content instead of _release-content. Fixes #23631.

@mockersf
Copy link
Copy Markdown
Member

mockersf commented Apr 3, 2026

a quick look over the 200 opened PRs with recent activity shows that 39 still touch the release-content folder

before doing this, we should either:

  • merge or close those PRs
  • update them
  • start preparing the release branch

whichever happens first

@mockersf mockersf added the S-Blocked This cannot move forward until something else changes label Apr 3, 2026
@Zeophlite
Copy link
Copy Markdown
Contributor

Surely we should merge this so main is correct, and block the other PRs on updating to the _ folder?

@alice-i-cecile alice-i-cecile added S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it and removed S-Blocked This cannot move forward until something else changes labels Apr 3, 2026
@alice-i-cecile alice-i-cecile added this to the 0.19 milestone Apr 3, 2026
@alice-i-cecile
Copy link
Copy Markdown
Member

I agree with @Zeophlite here @mockersf. We can just do this again if more slip through.

@alice-i-cecile alice-i-cecile added this pull request to the merge queue Apr 3, 2026
@alice-i-cecile alice-i-cecile removed this pull request from the merge queue due to a manual request Apr 3, 2026
@mockersf
Copy link
Copy Markdown
Member

mockersf commented Apr 3, 2026

Surely we should merge this so main is correct, and block the other PRs on updating to the _ folder?

I prefer to block tooling that can be easily worked around, than features or bug fixes 🙂
But happy to not block if all PRs are updated!

I agree with @Zeophlite here @mockersf. We can just do this again if more slip through.

Merging a PR isn't "free", it costs a lot in various CI... and I prefer not to merge PRs that will maybe need to be redone later and are not blocking now.

Also, keeping the issue / this PR opened and in the milestone is a very good reminder to recheck when creating the release that everything is in the correct folder

@mnmaita
Copy link
Copy Markdown
Member

mnmaita commented Apr 3, 2026

@mockersf I'm disregarding any potential costs with this but, would bulk-removing then re-adding the migration guide label help for those PRs? I just added the label to one of them and the GitHub bot correctly reported that the migration guide was missing (because it was under the old release_content directory).

@alice-i-cecile
Copy link
Copy Markdown
Member

Yeah, resetting the migration guide label is fine, but it's probably easier and clearer just to copy-paste a comment to these authors telling them to update their PRs :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Recently Merged release-content is in the wrong directory

5 participants