Add initial canary changelog

[mattcarrollcode]

No description provided.

[react-sizebot]

Comparing: e61a60f...6644d63

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.min.js	=	174.53 kB	174.53 kB	=	54.29 kB	54.29 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js	=	176.61 kB	176.61 kB	=	54.94 kB	54.94 kB
facebook-www/ReactDOM-prod.classic.js	=	565.12 kB	565.12 kB	=	99.42 kB	99.42 kB
facebook-www/ReactDOM-prod.modern.js	=	548.98 kB	548.98 kB	=	96.50 kB	96.50 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against 6644d63

[sophiebits]

In addition to what Andrew raised, how are people meant to update this when making changes? You won't know what version it is until after it's merged, and also you will get merge conflicts galore if many PRs change this file.

One possibility might be to generate from commit messages somehow. Another that I have seen projects use is to add changelog entries to a hidden folder in the repo root with an autogenerated file name (like .changelogs/chocolate-carrot.yml or something) to avoid conflicts then a tool to bulk copy them to the changelog and delete the files, which could even be done by the automatic canary publishing process. I can't find the tool I'm thinking of though at the moment.

The other thought I had is what if you change some behavior from A to B in canary, then from B to C later. If someone is consuming canaries then they want to hear about both of these but if they are coming to canary from stable (or if we're generating the stable release notes) then we only want to mention the change from A to C, not two changelog entries.

Or are there just not gonna be that many entries and I'm overthinking it.

(Sorry if any or all of this has been discussed already and I missed it.)

[mattcarrollcode]

How are people meant to update this? In addition to what Andrew raised, how are people meant to update this when making changes? You won't know what version it is until after it's merged, and also you will get merge conflicts galore if many PRs change this file.

One possibility might be to generate from commit messages somehow. Another that I have seen projects use is to add changelog entries to a hidden folder in the repo root with an autogenerated file name (like .changelogs/chocolate-carrot.yml or something) to avoid conflicts then a tool to bulk copy them to the changelog and delete the files, which could even be done by the automatic canary publishing process. I can't find the tool I'm thinking of though at the moment.

The other thought I had is what if you change some behavior from A to B in canary, then from B to C later. If someone is consuming canaries then they want to hear about both of these but if they are coming to canary from stable (or if we're generating the stable release notes) then we only want to mention the change from A to C, not two changelog entries.

Or are there just not gonna be that many entries and I'm overthinking it.

(Sorry if any or all of this has been discussed already and I missed it.)

This are all great points. Thank you for all these thoughts.

My thought with creating this was that there shouldn't be too many changes to the canary since there is a fairly high bar for adding things to canary. I was thinking that we don't need to couple changes in React to updating the changelog and that a PR to update the changelog could come later.

I was thinking that the main audience for the canary change logs would be framework and library authors that are doing 1 of 2 things:

1. a framework/lib author has upgraded to the latest canary version from their previously pinned version and something breaks and they need something to guide then as to where look for what might have changed between versions

2. a framework/lib author is looking to add support for a certain feature and wants to know what release channel to use or what the minimum canary version bump they need to support the feature

The reason this is being created now is so we have a place to canonical place to tell devs when features are ready for adoption by libs and frameworks. Namely server actions were recently promoted to the canary release channel and we don't have a place to document this at the moment hence this PR.

@acdlite expressed an interest on another channel in having similar info on react.dev instead of in this repo. If we want to do something more complex (e.g. a autogenerated change log) I think we should look at creating a flow that publishes nicely formatted change logs to react.dev. But this would be a non-trival undertaking (e.g. most of the canary changes to enable server actions were just flag flips, the code was already in the release). I hadn't considered the audience that is coming from a stable release to a canary release but I imagine we could cover this use case with a automated changelog script.

I think I'd still like to merge this PR as a stopgap so we have a place to document canary changes and look into a better solution long term after we get the server action documentation finished on React.dev.

[sophiebits]

If all you're worried about is giant features then sure let's update it manually and only occasionally. If we want lists of bugfixes like our release changelogs typically have (even canary consumers may be interested in when bugs they have run into get fixed) then we'll need a better process I think.

[mattcarrollcode]

Had a chat with @acdlite offline, I'll merge this for now and we'll explore better options moving forward.