Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation and context:
The content of
version.py
is repeated in all of our repos, so we should template it.Interactions with other PRs:
This is based on #39 , but so much has changed since that PR that it was easier to just start fresh.
The main difference functionally from #39 is that we don't internally generate the version string to be used statically in other files (e.g. setup.py and docs/conf.py). The version in those files is still determined dynamically by importing
version.py
. There were two reasons for this.In this PR templating
version.py
isn't mandatory, so we can't count on the static version info being available. However, we could work around this by having conditional logic that uses a static version ifversion.py
is templated otherwise falls back to the dynamic import.This PR also supports calendar versioning, which complicates the generation of a static version. The
bones-check
during CI would be updating the static version each time, which means that we'd have to manually update the static version in every repo each month orbones-check
would fail. Again we could work around this by having conditional logic that uses a static version if you're using semantic versioning but falls back to the dynamic version if you're using calendar versioning.So as mentioned we could work around both of these limitations with some conditional logic. But I just wasn't sure that adding that complexity is worth it, given that we're doing everything dynamically currently and it's working well enough.
How has this been tested?
Added a test (and it's used to template version.py in this repo).
How long should this take to review?
Types of changes:
Checklist: