Closed d33bs closed 2 months ago
Thanks @jenna-tomkinson !
I do have one question now that I think of it, is there a need to include a test for this? I see it isn't checked off in the original comment for the PR.
I like your test-driven thinking here! I'm inclined to say "yes" and created #9 as a result. I'm cautious to add a test yet for this now as things may change and versioning might be something tested alongside releases and deployments. I also think it may involve somewhat complex testing outside of pytest
. The pseudocode for testing something like this could look like:
poetry build
__init__.py
file for an accurate version specificationNote: after this PR was merged I found the tag was dropped. I've manually applied this post-merge using the git
CLI.
Description
This PR adds versioning capabilities for this project to help distinguish between different versions. Here's a story to help contextualize these changes: "As a person using
SCulptQC
I need to know what version of the software I'm using to help with package management and troubleshooting when necessary." Usingpoetry-dynamic-versioning
helps ensure any installation of the package is described by a "dynamic version", one which takes into consideration semantic version git tags as well as commit hashes beyond a version tag.I've added a tag for
v0.0.1
to help indicate this initial version we're working towards. Later versions I feel might be best specified through GitHub Releases work in #6 . I also added apoetry-check
to help avoid issues with the lockfile being out of alignment.Thanks for any thoughts and feedback you may have!
Closes #5
What kind of change(s) are included?
Checklist
Please ensure that all boxes are checked before indicating that this pull request is ready for review.