Open ferdia-sopermaccafraidh-lrn opened 3 weeks ago
💠thought (non-blocking): We could potentially use autogenerated release notes as the single source of truth for the Changelog instead of Changelog.md
to avoid further duplication now that Github Actions are being used for deployment?
💠thought (non-blocking): we could potentially remove _version.py
from source control as well so it's fully controlled by this process to avoid confusion?
Autogenerating version.py
is a good idea. Removing it from Git may be, too, but I worry this might break the SDK if running from a Git clone, so worth checking first.
Autogenerating
version.py
is a good idea. Removing it from Git may be, too, but I worry this might break the SDK if running from a Git clone, so worth checking first.
@shtrom I'll investigate the consequences of removing version.py
when building the locally installable version to see if there's any issues if we remove this and leave it only for releases to add.
Overview
Proposal to use the git tag created via the release process as the library version to avoid confusion. This works well with the new workflow added by @walsh-conor.
Context
This came out of my initial experience with #80 where after creating a pre-release, it has overwritten v0.3.8 in
PyPI
, as when creating the release,_version.py
was still used. https://github.com/Learnosity/learnosity-sdk-python/releases/tag/v0.3.13-preTesting
This has been added to the documentation for contributing and has been verified to work in this action run. https://github.com/Learnosity/learnosity-sdk-python/actions/runs/10524888118
You can see that a tag was pushed and this was successfully set as the library version via the output from
twine check dist/*
where the tag pushed wasv0.3.14-rc0
.Changes
Checklist