Branches, Pull requests and Releases

[FBumann]

Branches

As we start to think flixOpt in Releases, we decided to introduce multiple dev-branches instead of only one:
Following the Semantic Versioning guidelines, we introduced:

next/patch: This is where all pull requests for the next patch release (1.0.x) go.

next/minor: This is where all pull requests for the next minor release (1.x.0) go.

next/major: This is where all pull requests for the next major release (x.0.0) go. (not needed yet)

Everything else remains in feature/...-branches.

Pull requests

Every feature or bugfix should be merged into one of the 3 release branches, using Squash and merge or a regular single commit.
At some point, next/minor or next/major will get merged into main using a regular Merge (not squash).
This ensures that Features are kept separate, and the next/...branches stay in synch with ``main`.

Remember to update the version in pyproject.toml

Releases

As stated, we follow Semantic Versioning.
Right after one of the 3 release branches is merged into main, a Tag should be added to the merge commit and pushed to the main branch. The tag has the form v1.2.3.
With this tag, a release with Release Notes must be created.

This is our current best practice

[FBumann]

Any thoughts @baumbude @PStange ?

[baumbude]

Ok, und dann müsste der merge in den main von release Branch A anschließend immer zu einem händischen Update in den release-Branches B und C führen.