CHANGELOG_AND_TAGGING.md

Why

Keeping a changelog and tagging the releases serve various purposes

Easy identification

It's easy to identify the differences between versions (e.g. Production vs Staging) so everyone is aware of what is running at a server just looking at the CHANGELOG.md

Helping the Product Team

Sometimes the product team may not be fully aware of what are we deploying or what the differences are between what is deployed vs what we are testing. The CHANGELOG.md will be easier to understand than checking commit messages. Commit messages are much more technical oriented and written for developers instead of customers/managers.

Visibility

All the team will be much more aware of what are we deploying if we have a single document with a section explaining it. Specially if a release involves merging several branches (which is not unusual)

Steps to update the CHANGELOG

1. When branching out, edit the CHANGELOG.md and add an "Unreleased" section on top
2. The section will have subsections (in needed) for
   • Added
   • Changed
   • Deprecated
   • Removed
   • Fixed
   • Security
3. Add the appropriate entries on the corresponding subsection
4. When merging to master (or the destination branch) we will end up with one Unreleased section with one or many subentries

Steps to deploy

1. Choose an appropriate tag using v#{version}.#{minor_version}.#{patch}
2. Rename the Unreleased section with the version number and date
3. Commit the change
4. Tag the commit
5. Deploy

NOTE: See Keepaachangelog for more information