Terminology

• Breaking changes are changes that are not handled by the Migration Assistant of Vadere. That is old scenarios are either adapted manually or are not working with newer versions of Vadere.
• Major releases usually include substantial (potentially breaking) changes, but of course also minor changes.
• Minor releases usually contain bug fixes, new additional features, etc.

Follow all steps for major and minor releases

• Decide for a new version number [MAJOR].[MINOR] e.g. 1.1 (this is not a decimal number, so after 1.9 the version 1.10 can follow for a minor release). Increment the current number by 1, corresponding if it is a major or minor release.

• Are there any open merge requests that are important to be integrated into master so that it is included in the new release?

• Are all unit tests on master passing? (wait for CI to be completed)

• Adapt the CHANGELOG.md file on master. Change

## In Progress:

to

## v[MAJOR].[MINOR] (YYYY-MM-DD)

where YYYY-MM-DD is the release date.

• Update all scenario files with the Migration Assistant (if possible)

  • Important (git tracked) scenarios to update are contained in folders VadereModelTests/ and VadereScenarios/
  • Follow the steps from the Migration Assistant wiki page
  • Commit and push all updated scenarios to master with commit message Release [MAJOR].[MINOR]

• Merge master into branch stable. Run in the console:

git checkout stable
git merge master

• Add a new tag to the new release on branch stable. Use the new version number for the tag. Run in console:

git tag -a v[MAJOR].[MINOR] -m "Release of version [MAJOR].[MINOR]"
git push
git push --tag

• Checkout back to branch master (git checkout master) and prepare for the ongoing development and releases. For this, change the CHANGELOG.md file again and insert the new lines on top:

## In Progress:

### Added

### Changed

git commit -am "Prepared CHANGELOG.md for next release."
git push