Begin formal versioning

[paulapreuss]

Considering the size of the project and the upcoming number of changes, I propose to begin formal versioning of the open plan app and keep a CHANGELOG. This is a first setup / suggestion for a general versioning workflow to implement into the project. Let's have a conversation about it :)

Notes

• I have given this first version of the app the number version 2.0.0. This is mostly arbitrary, but I thought it would be fitting considering that the running project is open-plan 2.0 and we have already deployed a first big revamp of the app.
• The app version number is now displayed in the footer.
• The proposed versioning is semantic (major.minor.patch).
• We can discuss the workflow and also if there should be one person responsible for keeping track or anyone can bump/tag releases. Here is what I suggest so far - let me know what you think.

Proposed worflow

• There is now a CHANGELOG.md inside /app. Whenever a PR is opened, the changes introduced should be added to the changelog under the [Unreleased] tag. The changes can be split under Added / Changed / Fixed / (Breaking if any) headers. I suggest to also add a link to the respective PR in the changelog entry.
• This means that as PRs get merged, changes accumulate under the Unreleased tag in the changelog.
• Once enough changes have been made to warrant a new version or the updates should be deployed (not after every PR), the app version would be bumped on main with the help of bump-my-version.
• Concrete workflow: Merge changes -> pull main --> bump-my-version bump major/minor/patch
  • Updates the version numbers in the app
  • Replaces the [Unreleased] tag in the changelog with the new version number and the date, and creates a new [Unreleased] tag
  • Creates a bump commit with these changes
  • --> push bump commit to main
• Once the code should be deployed to production, merge main into production (same procedure as right now, which will trigger a new build). Here we can also use a standardized PR name such as Release v{version} or Merge v{version} into production.

Tagging

• I suggest to tag releases once deployed from production (git tag -a v{new_version} -m "Bump version: {current_version} → {new_version}")
• Alternatively, we could implement a github actions workflow that automatically tags releases when a PR with a new version is merged into production.