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

Highlight breaking changes and disruptions more prominently in the CHANGELOG #441

Open
anaelleltd opened this issue Aug 22, 2024 · 2 comments

Comments

@anaelleltd
Copy link
Collaborator

This is part of the overall strategy to standardise and improve runtime releases management.

Over the past 3 months, I have been pushing targeted notifications into the community to advise network builders and teams about upcoming breaking changes (e.g PR 337) and disruptions (e.g PR 414, PR 350 and PR 344). These notifications aim to provide the following information: 1) what kind of changes the PR introduces, 2) who will be affected by theses changes in practice, and 3) how the team/builders affected need to follow up.

I have recently proposed to update the docs and PR template in the runtimes repo (PR 439) as the first step for formally onboarding all code contributors to this new process. The second step would be to update the current structure of the CHANGELOG to highlight reported breaking changes and disruptions more prominently.

This could be done by creating 2 new sections ad hoc in the CHANGELOG:
🚨 Breaking changes 🚨
🚧 Disruptions 🚧

More options/alternatives for getting this done need to be proposed/discussed so that we choose the most convenient and workable solution.

cc: @bkchr @joepetrowski @kianenigma

@ggwpez
Copy link
Member

ggwpez commented Aug 26, 2024

I added some note like this now, but it is not really machine readable. Eventually we may also want to use prdocs here if it does not cause too much churn. They can then define major for breaking changes, just like we do in the SDK.

Screenshot 2024-08-26 at 13 10 43

@bkchr
Copy link
Contributor

bkchr commented Sep 2, 2024

Eventually we may also want to use prdocs here if it does not cause too much churn

Generally we can.

They can then define major for breaking changes

However, this sounds like a hack.

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

No branches or pull requests

3 participants