Semantic Versioning for BACK Stack Releases

[morey-tech]

We should implement a workflow for semantic versioning of the BACK stack components to clarify the differences between releases and targets for end users.

Suggested workflow:

• Changes to the main branch result in a new release candidate for the next semantic minor version.
  • The current version is 0.1.0, so changing the main branch will result in the 0.2.0-rc.1 tag. The next change will result in 0.2.0-rc.2, and so on.
• Once ready, we will cut a new release (manually trigger for now).
  • So if 0.2.0-rc.2 is the current release candidate, we will release 0.2.0.

This should be (relatively) simple to implement with a GitHub workflow. The existing release workflow cuts a new tag with the commit sha for each push to the main branch. This should be modified so that the release workflow handles generated the new version tag and then build steps are moved to a new build workflow that is triggered by the creation of a new tag.

[kurktchiev]

I might have to think about this a bit more on my end. Still, due to how Porter changes have to be built and bundled, the current SHA schematic works out better during development than tagging something with an RC, as I feel it would give a false impression of stability.

[kurktchiev]

One thing to also add is a targeted build action as currently we build backstage, config and porter on push and should rather check for changes in the backstage dir before attempting builds of that pkg

[morey-tech]

I feel it would give a false impression of stability.

Given that we are working in the 0 major version, it should be clear that we are in the initial development and give the impression of fragility.