Versioning strategy

[tlpss]

Describe the feature you'd like

As we are starting to use 'distributions' (see #91 ) of the code instead of simply using local installations, we will probably need to start using versioning to allow for using multiple versions of the code in parallel (e.g. don't want to propagate breaking changes during a course or during an almost-finished research project).

Use cases

• develop reproducible projects based on top of the codebase, withouth having to worry about breaking changes in development, though we might want to patch bugs or selectively propagate features for e.g. a course or a research project.

Possible implementation

• global version for all packages (1 on 1 correspondance with branches), and each package is only guaranteed to be compatible with other packages of the same version.
• local version for each package, this requires specifying all compatibilities between the packages but the benefit would be not to bump packages unnecessarily (though I don't see practical issues with this actually).

[tlpss]

@Victorlouisdg

[tlpss]

in this post, they also argue for using a global version for the mono repo to avoid internal dependency issues etc.

https://blog.aspect.dev/versioning-releases-from-a-monorepo

[tlpss]

all the now remains to be done is to select a release scheme.

Either we do semantic versioning, or we have another scheme that more directly associates a version with each commit on the main branch.

I think that strict semantic versioning is too much for us right now (would have to think about breaking changes etc, for now we don't want to worry about breaking changes too much).

, so I would like to use a date/commit SHA based scheme for releasing (possibly with 0.0.X semantic versioning) .

The main issue seems to me to be keeping the version ids of the setup.py files up to date without too much manual hassle? (would be annoying to do this for every commit manually I think).
Could possible create gh action that amends commits to update the version IDs? but still need to be able to make actual releases.. furthermore, it would create a lot of tags and distributions?

[tlpss]

https://github.com/marketplace/actions/github-action-for-committing-changes-to-a-repository

[tlpss]

could also do something like the drake nightly builds https://drake.mit.edu/pip.html#nightly-releases