Changelog simplification

[ncave]

@MangelMaxime Do you think it makes sense to go back to tagging changes in changelog with applicable languages, instead of having to repeat the same change in all applicable language sections?

Obviously a personal preference, but IMO getting rid of the per-langage sections in the Changelog would simplify it and make it more readable by avoiding unnecessary repetitions.

* [JS/TS] Some change (by @contributor)
* [Python/Dart/Rust] Some other change (by @contributor)

[MangelMaxime]

Hello @ncave,

I am also having issues with how we handle changelog now days because it is a chore to maintain it.

We can give it a try to moving to a tag system like you are proposing.

I will also not be so "strict" (for a lack of better word) to always include the link to the PR. I think we can include the link of the issue if it exists and the PR link is optional as it is a pain to:

1. Create a PR
2. Add a new commit "Update changelog"
3. Push it again

Using "Squash and merge" already made an improvement as it is not part of the Git history anymore but let's make that even more simpler.

I am having plan to generate the the changelog based on the Issues / PR tags like that we can control everything easily using the Github UI. And have it automatically generated but it will take some time before I can experiment with that and I will first do it in a much simpler repo than Fable.

I am doing a release this evening like that we can start using the new changelog format on a fresh state.

For notification purpose @nojaf @dbrattli, and of course if you have a different opinion please voice it in. 😇

[MangelMaxime]

Also, the problem with current changelog is that I don't know but in merge/rebase it seems like there are always issues.

For example, today I had to fix the changelog items order because some of the items where not under Unreleased but a released version. Hopefully, the tags will minimise this situation

[nojaf]

I agree that the per-section thing is a bit excessive.

When considering release note generation, we could also consider starting to use labels for each PR. Maybe that can help. If we do generate things, having good PR names would be essential.

(PS: don't worry about tagging me for this repo, I don't have notifications turned on for everything here)

[MangelMaxime]

When considering release note generation, we could also consider starting to use labels for each PR. Maybe that can help. If we do generate things, having good PR names would be essential.

(PS: don't worry about tagging me for this repo, I don't have notifications turned on for everything here)

Yes this is exactly my idea.

My ideas is to use the name of the PR for generating the changelog item. And use labels to say this PR needs to be included in this project changelog or another for example.

We could even have label to say this is a major, minor, patch changes and thanks to that be able to infer the next version number.

I have a local experimentation which use the GraphQL API of Github for getting the information we need and it seems possible to do. I just need to write a script and give it a try to have an idea of how feasible or not it is.