On 2019-03-26 10:46:43 -0700 (-0700), Tim Burke wrote:
On Tue, 2019-03-26 at 14:31 +0000, Jeremy Stanley wrote:
On 2019-03-25 10:55:29 -0500 (-0500), Sean McGinnis wrote: [...]
I would like to have cinder 2012.2 removed from PyPi [...]
I have done this now. We've been removing any old date-based versions from PyPI as we come across them, to avoid the confusion you've noted. Cinder 2012.2 release candidates and point releases are still available at https://tarballs.openstack.org/cinder/ as well as from tags in its Git repository.
I suppose it's a little late now, but isn't this exactly the use-case for the epoch component in PEP-440 [1]? There's no fixing the existing tags, but we could at least fix it going forward...
[1] https://www.python.org/dev/peps/pep-0440/#adding-version-epochs
You say this as if you think we would have completely missed that PEP 440 had a notion of epochs when we evaluated our various options for the coordinated SemVer transition some 4-5 years ago. In fact, you'll see the section immediately before the one you linked actually refers explicitly to our (at that time) impending transition away from date-based versions. ;) The main reason we opted not to add epochs is that there were but a scant handful of packages we'd published to PyPI with date-based versions, mostly by accident and almost none of which would have actually worked if you tried to `pip install` them. It *did* create some disruption[*] for OSAD's Kilo to Liberty upgrades on source-based installations, but as they were already in control of what versions their playbooks installed they were able to work around it by forcing a "downgrade" in the command used to install the packages they built. Distro package maintainers were going to have to add their own epochs anyway at the point our versions rolled "backwards," and not doing so in our Python packages avoided a number of sticky problems (epochs wind up embedded in your sdist filenames, PBR would have needed a new feature to support having the epoch-prepended version number not match the corresponding Git tag, distros may have already added their own epochs on some packages so embedding ours could lead to confusion when they didn't match...). Part of the disconnect is that PEP 440 epochs treat sdist artifacts as built packages (same could be said for its support for local version identifiers and post releases), while we've considered them to be our source tarballs. As such, we want the sdist versions to match those we've tagged in Git. This approach is made possible primarily due to the fact that our projects are "pure python" and also because we don't vendor any content from other projects into our packages, so there is little need to distinguish the versions of our sdist (or even wheel) builds from the source code they directly bundle. [*] http://lists.openstack.org/pipermail/openstack-dev/2015-July/071034.html -- Jeremy Stanley