Repository navigation
Specify versions of nimi-python modules independently #1900
Description
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
- [ ] https://github.com/ni/nimi-python/issues/1965
- [ ] https://github.com/ni/nimi-python/issues/1966
- [ ] https://github.com/ni/nimi-python/issues/1967
Metadata
Metadata
Assignees
Labels
No labels
Activity
ni-jfitzger commentedon May 10, 2023
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 commentedon May 12, 2023
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 commentedon May 12, 2023
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.
ni-jfitzger commentedon Apr 24, 2025
@marcoskirsch I am removing the deprecation support subtask from this issue, so that we can close.
That subtask, which is also its own issue, will remain part of the milestone, which will remain open.
ni-jfitzger commentedon Apr 24, 2025
All sub-issues closed, so I'm closing this. Great work by our team.