Update strategy for main/develop

[tjhunter]

Describe the task. It can be a feature, documentation, etc.

The current situation (backporting specific changes to main branch) is brittle because of the dual-repo structure. We have a matrix of configurations that we need to check between the public and the private repo. The current main branch is broken because the following changes were not backported:

RE src/weathergen/utils/cli.py

#1464
#1668
#1573
#1738
RE src/run_train.py

#1675
#1573

Suggestion going forward: trunk development:

• stabilize develop (CI/CD, etc.) to keep it ready to cut
• fork a release to main on a monthly basis
• do a main release in a week (after the GA)
• no backports by default

Hedgedoc URL, if you are keeping notes, plots, logs in hedgedoc.

No response

Area

• datasets, data readers, data preparation and transfer
• model
• science
• infrastructure and engineering
• evaluation, export and visualization
• documentation

[tjhunter]

cc @grassesi @clessig

[grassesi]

I like this approach, for me the question is what should be the goals/tasks in stabelizing develop. For me it would be:

• working integration tests
• clean up/fix stale/broken configs in config/

[clessig]

The release to main should be on a 1-2 month basis depending on new features.

[grassesi]

How do we handle MR in the private repo that require certain changes in the public package to be implemented? Should we hold these changes until the next release in the public repo is scheduled, or would that be an occasion for a new release in the public repo?

[clessig]

How do we handle MR in the private repo that require certain changes in the public package to be implemented? Should we hold these changes until the next release in the public repo is scheduled, or would that be an occasion for a new release in the public repo?

We should have a tagged version in the private repo that is tethered to main.