Phoenix
Phoenix copied to clipboard
wxWidgets
release tag for 4.2.0 is missing
Operating system: all wxPython version & source: 4.2.0 Python version & source: all
Description of the problem:
Thrilled to see version 4.2.0 released (https://github.com/wxWidgets/Phoenix/blob/master/CHANGES.rst#420-rumors-of-my-death-are-only-slightly-exaggerated).
Please use git tag and push to github:
git tag 4.2.0
git push --tags
to generate a GitHub release at https://github.com/wxWidgets/Phoenix/releases
@swt2c um, and make a Github release from that tag?
The latest release is clearly advertised as 4.0.1 from March 2018 at both https://github.com/wxWidgets/Phoenix/releases and https://github.com/wxWidgets/Phoenix/
@swt2c 1) because it gives a very simple way for anyone to grab the source code at that point in the development tree, and 2) because it advertises what (and when) the latest release is to anyone who might be interested in development. FWIW, creating a Github release truly takes less than 1 minute. Less than the amount of effort to respond to this issue.
Why do you need to have the Github pages advertise a release that is more than 4 years old?
I'll let Robin decide if he wants to use GitHub releases (based on history, it seems he does not), but it seems the canonical location for releases/source distributions is PyPI (and if you really need a git bundle you can use the tag).
I don't like that it provides downloads based on the tag, which does not include everything that the official source archive does (none of the generated code will be present.) I can add a note telling people to not use them but they tend to still try to use them. But I can still see the benefit of having it there.
Done.
@RobinD42 Thanks. Yes, it probably is -- or at least should be -- obvious to anyone looking at the Github pages that the "Github release" reflects the state of the Github repository at the time of tag/release. That can be very different from the PyPI release, especially for repositories that use compiled code, but also those that have documentation, examples, testing scripts, and non-Python source code in the source tree that might not all be installed with pip.
Github: source, PyPI: contents of MANIFEST.
The Github release is very helpful (especially if they are in sync with PyPI releases) for various non-PyPI packaging systems like conda, MacPorts, brew, rpm, etc. They can be a clear sign to build/release a new package akin to the PyPI package. Those systems might even use a Github release as the trigger to build a new package.
Maybe that's all obvious.... Anyway, thanks very much, and do let us know how we can help.