🛸Flowcontrol

Appearance

✅ Versioning ​

This page goes over the versioning guidelines for the project. It includes the versioning scheme, how to update the version and how this all works together.

📝 Versioning Scheme ​

The project follows the Semantic Versioning scheme. This versioning system consists of three numbers separated by dots: MAJOR.MINOR.PATCH.

Since the shift to Vue 3, the project has been on major release 3.x.x This will continue to be the case until the next major changes and release. Some examples of changes that would warrant a major release are:

  • A complete overhaul of the project structure
  • A significant change in the way the project works
  • Switching to a new framework

Minor releases are for new features and changes that are backwards-compatible. Some examples are:

  • Adding a new page
  • Changing the layout of a page
  • Adding a new component
  • Adding a new API endpoint

Patch releases are for bug fixes and small changes that are backwards-compatible. Some examples are:

  • Fixing translations
  • Changing the color of a button
  • Fixing a redirect issue
  • Changing some images

📄 Implementation ​

Versioning is implemented in a couple of different manners.

The spring boot applications have a APP_VERSION variable in their application properties file. This value defaults to latest and is updated by the docker compose files. This happens for all environments. For development this value can be taken from your local .env file. Staging and Production use the GitHub vars to insert this value.

The Vue application has a VITE_APP_APP_VERSION variable in the vite.config file. When running the FE locally, it takes the value from your local .env file. When ran in docker, it takes the value from the docker compose file. This happens for Staging and Production (development doesn't include the FE in the compose file).

🔄 Updating the Version ​

  1. Change the version number in the GitHub vars section.
  2. Update the version number in the parent POM.xml file. (only for now. Looking to automate this from the GitHub vars)
  3. In your local .env you can change the value as well. This is not required but does introduce a bit of consistency.
  4. Inform the team about the changes that have been made so that they can change the version number in their local .env files.