Release v2.3.0 #134
Release v2.3.0 #134
Conversation
There was a problem hiding this comment.
LGTM, though I'd like to clarify the release process before approving/merging.
It seems like there's a partial process defined in a manually triggered workflow action (nice pattern TIL you can manually trigger github action workflows). Although since it was created we started using github actions more internally and now require external actions to be verified on the github marketplace. None of our other projects need wheels prebuilt, so I'm not familiar with that process either.
I'll also ask @thomasst how he's released this project in the past. If you can give me some direction then I'm happy to manually release it.
By following these docs it seems that you can allowlist specific GitHub actions to be run. The workflow makes use of |
movermeyer
force-pushed
the
release_2_3_0
branch
from
331e3dd
to
dcf3550
Compare
|
I wasn't able to get approval for allow-listing them, however I've forked them both into the |
movermeyer
force-pushed
the
release_2_3_0
branch
from
dcf3550
to
3be020b
Compare
movermeyer
force-pushed
the
release_2_3_0
branch
from
3be020b
to
482d7b1
Compare
| @@ -112,7 +112,7 @@ jobs: | |||
| - name: Build sdist | |||
| run: python setup.py sdist | |||
|
|
|||
| - uses: actions/upload-artifact@v2 | |||
| - uses: actions/upload-artifact@v3 | |||
| @@ -59,7 +59,7 @@ jobs: | |||
|
|
|||
| - name: Verify that the `release_version` is larger/newer than the existing release in PyPI | |||
| run: | | |||
| python -c 'import sys; from packaging import version; code = 0 if version.parse("${{ env.ciso8601_version }}") < version.parse("${{ env.release_version }}") else 1; sys.exit(code)' | |||
| python -c 'import sys; from packaging import version; code = 0 if version.parse("${{ env.pypi_version }}") < version.parse("${{ env.release_version }}") else 1; sys.exit(code)' | |||
There was a problem hiding this comment.
We were using the wrong version in this comparison.
|
@AlecRosenbaum I manually ran the GitHub Action against this PR, and it produced both the wheels and the source distribution: https://github.com/closeio/ciso8601/actions/runs/3752178439#artifacts ( From here, I'd suggest chatting with @thomasst about manually uploading these artifacts as part of a release on PyPI. Note: You can use the Test PyPI (test.pypi.org) to make sure you understand the process and things are working before doing the real release. Alternatively, we can look into completing the automation in the workflow, but that's a non-trivial amount of work for right now, and I'd rather see a release finally done (after 14 months) than delay any longer. |
|
Done, v2.3.0 is now uploaded to PyPI. I've done some basic testing (and did so on test pypi too before uploading to actual pypi). From what I can tell it's working correctly when I do a pip install of Thank you @movermeyer! |
|
Thank you @AlecRosenbaum! It's great to finally have a release after so long and so many fixes and improvements! ❤️ |
What are you trying to accomplish?
New release to include the bug fixes from #113 and #116.
It also includes the performance improvements of #130
It also includes the spec coverage improvements of #139 and #140
What approach did you choose and why?
Bumping the version number and update the CHANGELOG. The usual.
I chose v2.3.0, since it expands the behaviour/scope of
ciso8601(with ordinal-dates and week-dates)As a fun aside, with #130,
ciso8601is now 3x faster at parsing timestamps with time zone information than it was before v2.0.0