Prepare for a 0.13.0 release #1094
Conversation
| * create source dist `python setup.py sdist` | ||
| * create wheel (with 2 and 3 support) `python setup.py bdist_wheel --universal` | ||
| * Sign the dists `gpg --detach-sign -a dist/tuf-vA.B.C.tar.gz` | ||
| * Upload to test PyPI `twine upload --repository testpypi dist/*` |
There was a problem hiding this comment.
Can't currently perform this step, as @vladimir-v-diaz is the owner of that package on test.pypi.org
joshuagl
force-pushed
the
joshuagl/v0.13.0
branch
from
3d4443d to
5b03778
Compare
There was a problem hiding this comment.
Many thanks for preparing this release, and big kudos for adding a RELEASE.md document, @joshuagl. ❤️
The former definitely looks good to me. I double-checked that all PR numbers point to the right PR and no important PRs were omitted. You only left out dependabot PRs and a few minor changes that probably could be added to the changelog but don't need to, i.e. #1021 #1028 #1044 #1051 #1072 #1086. Maybe double-check if you left them out on purpose or not.
In RELEASE.md I left a few comments, feel free to address as you see fit. Thanks!
💯 💯 QQ: would it be possible to formalize |
|
I would also probably hold off until we merge some important fixes, including #1091 |
I may have missed, #1072, but mostly those PRs were things I opted to ignore because I didn't think they were particularly interesting. I'd be happy to include the PRs you mentioned, or not, and add some additional text to Personally I prefer a changelog to include notable changes, rather than all changes. However I realise even that is subjective and there are entries I added to the changelog for this release that don't meet my own criteria for notable. I welcome thoughts on changelog curation. In the past I've followed similar principles to https://keepachangelog.com/, which would suggest editing the changelog here to group similar changes and clearly delineate new features, changed features, fixes, security issues, etc. |
Agreed, scripting some of this would be good. I'll take a look at that in future. |
I'm hoping to get into the habit of releasing more regularly. docs/ROADMAP.md suggests the project releases every 3 months. I'd like to get closer to that, so I don't think in general we should worry too much about holding a release for fixes. #1091 specifically, though, I'd be happy to merge and include in the release |
Write down the expected steps for a maintainer to follow when making a release of tuf Signed-off-by: Joshua Lock <[email protected]>
Signed-off-by: Joshua Lock <[email protected]>
joshuagl
force-pushed
the
joshuagl/v0.13.0
branch
from
5b03778 to
ea958bc
Compare
https://keepachangelog.com provides good advice on curating a changelog Signed-off-by: Joshua Lock <[email protected]>
I've merged this PR and included it in |
👍 This all makes sense and aligns with what I thought. Just wanted to double-check. :) Thanks for adding a link to the changelog guide to RELEASE.md. |
Categorise changes by type, per the recommendations at keepachangelog.com Signed-off-by: Joshua Lock <[email protected]>
These additional URLs will be displayed on PyPI: https://packaging.python.org/guides/distributing-packages-using-setuptools/#project-urls Signed-off-by: Joshua Lock <[email protected]>
joshuagl
force-pushed
the
joshuagl/v0.13.0
branch
from
2c0c643 to
eb1c8d0
Compare
Fixes issue #: N/A
Description of the changes being introduced by the pull request:
Please verify and check that the pull request fulfills the following
requirements: