Development Process
main dev work is done on feature branches Branches must be prefixed according to their nature:
feature/* - for implementing user stories fix/* - for fixing bugs that appeared in the main branch chore/* - any small change without any impact on the software Branch Name:
MUST contain : Issue ID in the format #XXX MUST contain: Subject of issue (Abbreviation of JIRA summary without using spaces / use "-" to connect)
feature/#999-arc42-documentation
chore/#563-preparation-moving-repository-to-tractus-x
fix/#666-fix-npe-in-processing
- To create a fix for an already release version, proceed as following:
- Create a branch from the tag you want to provide the fix for. (Use the branch naming convention mentioned above) ** Implement your fix on a separate branch (Branch has prefix fix/)
- Create a GitHub Release with ** target is your fix branch ** tag is the new fix version (e.g. when creating a fix for 2.0.0, tag will be 2.0.1) ** Title is the new version ** add changelog entry in CHANGELOG.md
- Create a PR from your hotfix branch to main
- Best practice https://keepachangelog.com/en/1.0.0/[keepachangelog.com]
- Add release notes for new version in CHANGELOG.md
- Features of your product(s) or component(s), available for market entry
- Please provide minimum 5 to maximum 10 key feature descriptions
- Use category “ADDED” as per good practice
- Known knowns as of the baseline of our recent Gate4 reviews (for example these can be unresolved bugs (also medium ones) or SEC weaknesses etc.)
- Put yourself into the position of an “external” customer/user of your software and focus on what is worth mentioning (if anything)
- Create a category „KNOWN KNOWNS“ if applicable
- Make sure, your Changelog.md fully correlates to your market-entry version
IRS using semantic versioning three-part version number. https://semver.org/
- If there are any incompatible API changes.
- Changes with high impact
- Contains new features and changes with critical business impact.
- Full regression tests are covered.
- Add functionality in a backwards compatible manner
- Features (backwards compatible has to be ensured)
- Minor release does not add features or changes with critical business impact.
- Regression impact should be low.
- No training effort necessary
- INT Test environment should be stable. No changes on depending on systems required. No changes on consumer side necessary.
- Operational risks should be low.
- Backwards compatible bug fixes
- Bug fixes and Hotfixes
- Covers Bug fixes and changes with no critical business impact.
- No changes on depending on or consuming systems required.
- INT Test environment should be stable. No changes on depending on systems required. No changes on consumer side necessary.
- Defined software state.
