Specify versions of nimi-python modules independently

[ni-jfitzger]

Description of issue

Currently, all nimi-python modules release at the same time with the exact same version, regardless of what changes were made to each individual module.

This violates the spirit of semantic versioning.

To allow specifying of different individual versions, the following needs to be done:

• Split ReadTheDocs documentation
• Use multiple module-specific version tags for each release
  • Can this be done?
• Handle testing dependencies
  • There may be nothing to do here

Of course, the work to actually specify versions needs to be done, as well.

Tasks

Preview Give feedback

1. Split nimi-python documentation and ReadTheDocs project #1965
   codegen docs +2
   
2. Add "deprecated" functions, enums, enum values, attributes to nimi-python's code generator #1584
   +0
3. Update CHANGELOG system for independent package versioning #1966
   +0
4. Update release process for independent package versioning #1967
   +0

[ni-jfitzger]

There's also changelogs to consider. Maybe put individual changelogs in src/, so that we can maintain the version separately?
Alternatively, keep a single changlog and group by release data, specifying individual versions for each package.

For release tags, I believe we can just create individual releases and include the name of the package in the tag. There are other examples of monorepos that do this, like https://github.com/conventional-changelog/conventional-changelog/tags.

I don't know how this might complicate the automated uploading of documentation to ReadTheDocs. That's something to look into.

[ni-jfitzger]

Clarification on the issue description:

We were technically already capable of specifying different versions for each package, we just haven't.
The main difficulty with doing so is "What version do we specify for the docs and the repo tags?"

We could just use the latest of any package version, but that forces us to release everything, every time (in case other packages catch up in version with the latest versioned package in a release where it isn't bumped). Another difficulty with that is that it can be confusing to users looking for a specific version of the docs or repo that goes with a particular version of a module.

[ni-jfitzger]

An alternative to semver is discontinuous semver, a concept where the package version is the same across the repo, but not everything releases every time.