Preparing Code for Release
Once the release scope has been defined and confirmed with the Product Managers, the next step is to prepare the code for release. This involves verifying that the develop branch contains only the intended features and bug fixes, by reverting any unintended changes from the release branch before proceeding, and updating the version numbers according to the versioning strategy to ensure proper tracking, consistency, and deployment of the release.
Code Rollback
Sometimes, experimental features might be added to the develop branch to allow Product Manager to test
these features without them having to locally spoof these changes.
An ongoing effort to provide a testing-firm to each Pull Request is still in-progress.
Once all necessary changes are deployed and in-place, we will no longer directly merge features to be tested
to develop branch without it passing the Quality Assurance step in these PR-firms.
It could also happen that the newly introduces features are insufficiently tested or still contain bugs to be resolved.
In these cases, a code rollback is necessary to remove these unverified changes from the upcoming release.
We illustrate two ways of achieving this goal.
Using the revert PR feature of GitHub is usually the easiest to revert these unintended changes.
However, it might not always work due to changes applied to the affected code,
or when the changes become too complex to revert.
In such cases, use Git CLI to manually bring the codebase to an acceptable state.
Use a single Pull Request for a bugfix or a feature request to the develop branch. This allows developers to easily identify and rollback changes, and to reapply them afterward.
You can split a large feature request into multiple smaller Pull Requests,
but it needs to be merged in to another aggregating branch for that feature.
Once completed, create a Pull Request from the aggregating branch to develop branch.
% TODO! Illustration using Mermaid.
Rollback Changes Using GitHub
Rollback Changes Using Git CLI
Template Updates
This section only applies when template updates need to be released.
The Product Manager is responsible for informing the release developer whether template updates are part of the release scope and for providing the corresponding template version to be released.
Rigorous processes are established to ensure the correctness and the integrity of the template released.
C
Update Product Version
Properly updating the product version during each release is crucial for effective version tracking, consistency, and deployment. It allows developers, Product Managers, and end-users to easily identify the specific version of the software they are working with, and it creates a snapshot of the software’s state at the time of release, serving as a reliable reference point for future maintenance, debugging and release purposes.
Versioning Strategy
To maintain consistency and simplicity across all our products, we use the date-based versioning strategy.
In this strategy, the version number is derived from the release code completion date in the format YYYY.M.D,
as an example: 2025.9.10. Do not add leading zeros to the month or day components.
Preparing Release Branch
Once the codebase is ready for release and the product version numbers are determined, we can prepare for