Is your feature request related to a problem? Please describe.
There is no easy and centralised way for checking the changes being introduced in a new release. Sometimes the API is broken and there needs to be deprecation warnings issued at least a few minor releases ahead.
Describe the solution you'd like
A version-controlled CHANGELOG included with the repository (as a markdown file) which gets updated incrementally during all the PRs that lead up to a particular release. It gets finalised in the release/x.y.z PR before merging into master. Some points:
Chronologically reverse
Each contribution/feature should be linked to corresponding PR
Each release date should also be included
Changes should be grouped by types:
Added for new features.
Changed for changes in existing functionality.
Deprecated for soon-to-be removed features.
Removed for now removed features.
Fixed for any bug fixes.
Security in case of vulnerabilities.
After new release, create an Unreleased section at the top of the changelog which then gets updated both during PRs by individual contributors as well as when the team decides to work on and implement a certain future. This allows for a simple Coming soon... as well as makes it easy to prepare the final CHANGELOG during the release PR. More details here.
Describe alternatives you've considered
Discussions on Slack/Rocket.chat, fragmented notes in various PRs, Issues and meeting docs, some minimal points in the Github Releases section. None of this has archival and reference usage and are also difficult to maintain, aggregate and version control.
Additional contextRelated: As discussed in the comments on PR #87 we need a well-structured commit message for the merge commits when we merge a branch into dev during the usual development cycle. The expected template for this is as below:
Short 1-line (50 chars) description of key feature/bug-fix with associated issue numbers if any (can go in the commit heading in Github PR merge UI)
(The part below goes in the merge commit message details)
Contributors: Full name (and not Github handle) of all contributors to this PR, irrespective of who made the code commits.
Longer multi-line description, typically in the form of a detailed list of various features implemented with any additional insights/remarks on the implementations etc.
It should be possible to implement this through an automated Github bot that notifies on every PR the requirements of updated tests, updated docs, changelog, commit message, CLA etc. Either enforce this through PR templates or through a github bot.
Is your feature request related to a problem? Please describe. There is no easy and centralised way for checking the changes being introduced in a new release. Sometimes the API is broken and there needs to be deprecation warnings issued at least a few minor releases ahead.
Describe the solution you'd like A version-controlled CHANGELOG included with the repository (as a markdown file) which gets updated incrementally during all the PRs that lead up to a particular release. It gets finalised in the
release/x.y.z
PR before merging intomaster
. Some points:Added
for new features.Changed
for changes in existing functionality.Deprecated
for soon-to-be removed features.Removed
for now removed features.Fixed
for any bug fixes.Security
in case of vulnerabilities.Unreleased
section at the top of the changelog which then gets updated both during PRs by individual contributors as well as when the team decides to work on and implement a certain future. This allows for a simpleComing soon...
as well as makes it easy to prepare the final CHANGELOG during the release PR. More details here.Describe alternatives you've considered Discussions on Slack/Rocket.chat, fragmented notes in various PRs, Issues and meeting docs, some minimal points in the Github Releases section. None of this has archival and reference usage and are also difficult to maintain, aggregate and version control.
Additional context Related: As discussed in the comments on PR #87 we need a well-structured commit message for the merge commits when we merge a branch into
dev
during the usual development cycle. The expected template for this is as below:It should be possible to implement this through an automated Github bot that notifies on every PR the requirements of updated tests, updated docs, changelog, commit message, CLA etc. Either enforce this through PR templates or through a github bot.