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
Process update: call out breaking changes in "What’s new in Gutenberg?" posts and changelog #19863
Comments
Copying Slack convo over (https://wordpress.slack.com/archives/C02QB2JS7/p1579861260026000):
|
The example I pointed out was actually highlighted at WP 5.2 changelog, as mentioned here: godaddy-wordpress/coblocks#1242 (comment) |
I guess we should highlight any changes that already have the "Dev Note" label for the next WP release. |
We still collect all breaking changes manually, correct? Could we partly collect them by letting the release tool parse our packages' changelogs? |
We include breaking changes mostly for tooling. I don't think that changelogs for UI related packages are often updated. It would be great to do that, but in practice, there is no data to process 😄 |
Quite true, unless we could raise potential breakage in the course of feature work (PRs). |
I'd love it if these posts featured the Gutenberg version in the title. They seem to be release announcements but the Gutenberg version number is not mentioned in the title. |
@sirreal Seems like a simple change we can do. If we forget on the next one, ping us :) |
+1 for the Gutenberg version in the title. It'll be a big help for me as I start pulling Gutenberg releases for distribution internally. |
Old issue, old convo; I think this served already for the change back then. :-) |
Is your feature request related to a problem? Please describe.
Changelogs for
@wordpress/*
package updates are great in that they are following semantic versioning and contain the "breaking changes" section in the changelog (example). 🎉Neither is true for Gutenberg plugin updates tho. 😞
For example in the latest update post and plugin changelog we had:
Describe the solution you'd like
A clear "breaking changes" section in the changelog would be helpful.
I don't mind if they're double, so the above example would be twice in the document. That way folks could only skim "breaking" section if they don't wanna read the whole thing.
Additional instructions on how to migrate would be helpful too.
"Upcoming breaking changes" could be another useful thing: so example of CSS class deprecation would be called out clearly upfront.
Describe alternatives you've considered
–
The text was updated successfully, but these errors were encountered: