This PR prepares mikeplus-python for an experimental release for MIKE+ 2024. The package will still not be deployed to PyPI. Users wanting to test out the package will need to install from this repository.

Additionally, this PR proposes a versioning and branch strategy for mikeplus-python.

Versioning

The versioning is consistent with this standard. I propose that releases be made in step with MIKE+ releases as follows:

• MIKE+ 2024 = MIKE+ PY v2024.0.0
• MIKE+ 2024 Update 1 = MIKE+ PY 2024.1.0
• Any mini releases / bug fixes of MIKE+ PY in between MIKE+ releases adds a trailing digit (e.g. MIKE+ PY v2024.0.1)
• There always exists a tag indicating the latest MIKE+ PY version for a particular MIKE+ version (e.g. MIKE+ PY v2024.0-latest refers to the latest MIKE+ PY version v2024.0.x)

Branch strategy

Using a single main branch is problematic because of the different MIKE+ versions. We want to make it easy for people to contribute, as well as to fix minor bugs themselves in a particular version they're using. For this I propose:

• The 'main' branch is always consistent with the latest public release of MIKE+
• The 'dev' branch is used for internal development versions of MIKE+
• We maintain branches for each release of MIKE+ (e.g. branch 2024.0, 2024.1, 2025.0, 2025.1, etc)
• All of the above mentioned branches should have appropriate protections.

If you have any other suggestions feel free to comment :)

I have already added some tags for v2024.0.0 and v2024.0-latest. It is back a few commits, since the latest main branch appears inconsistent with MIKE+ 2024 public release.