This adds semi-automated versioning to the project. The general flow is that every release is a rc by default (major, minor, or patch). We can increment the build number with pipenv run invoke version build, and you can promote a given rc to a final release with pipenv run invoke version release.
Testing
Run the following where $TYPE is one of major, minor, patch, build, or release. Ensure the scenario described in the summary holds true in your local environment.
pipenv run invoke version $TYPE
Checklist
[X] Confirm that any associated issues are indicated in the pull request title
[X] Rebase your PR against the latest commit within the target branch
[X] Include steps to verify and test the intended change
[X] Write or update unit tests and/or integration tests to verify your changes
[X] Run shellcheck against any new or updated shell scripts, indicating the reasoning behind any disabled checks
[X] Indicate whether or not this is a breaking change
[X] Ensure that any new dependencies are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0
JonZeolla
commented
3 years ago
Summary of the contribution
This adds semi-automated versioning to the project. The general flow is that every release is a rc by default (major, minor, or patch). We can increment the build number with
pipenv run invoke version build, and you can promote a given rc to a final release withpipenv run invoke version release.Testing
Run the following where
$TYPEis one ofmajor,minor,patch,build, orrelease. Ensure the scenario described in the summary holds true in your local environment.Checklist