search

sphinx-contrib / images

sphinxcontrib-images extension
Apache License 2.0
17 stars 14 forks source link

Release procedure (version number bumping) #10

Open jonascj opened 4 years ago

jonascj commented 4 years ago

I just did release 0.9.2 to PyPi and the release procedure is error-prone. Less now than when I release 0.9.0 and 0.9.1, but still error-prone.

At the moment the version number has to be changed in setup.py and sphinxcontrib/images.py manually. release-to-pypi.sh (which does not interact with pypi.org) checks if the two version numbers match and it checks if the lightbox2 submodule is initialized. That is an improvement over the 0.9.0/0.9.1 jumble...

When doing a test upload to test.pypi.org with twine you can only use any given version number for one test, so if you test with version 0.9.2 you can not retest with 0.9.2, but only with 0.9.3 or 0.9.2.pre2. This error-prone, having to change version numbers (to add .preN) to test on test.pypi.org and then have to change them back (and rebuild) before uploading to pypi.org...

Of course it is doable, but I'm open for suggestions to make it less error-prone. Any ideas @t-b ?

jonascj commented 4 years ago

Although the packaging best-practices and tutorials at packaging.python.org are hated by many, they offer quite a few solutions: https://packaging.python.org/guides/single-sourcing-package-version/

jonascj commented 3 years ago

I elaborated on the installation instructions in release-to-pypi.sh and I am bothered how much manual work is involed and how error-prone it is. Maybe github actions could be setup to do releases.

Anyway, a few times a year this method is still doable.

12rambau commented 2 years ago

I recently set-up a working workflow to update my libs to pypi, it's based on conventional commits and github actions. It allows to do a release and a changelog in one go with 1 commit and 1 tag. If you are still interested I can build a PR