Open anaelleltd opened 2 months ago
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.
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.
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