[infra][cinder] Removal of Cinder 2012.2 from PyPi
This is to make sure my request to infra is visible in case there are any concerns. On PyPi we have a "2012.2" release of Cinder. Since our version numbering scheme changed to follow semver, these year-based version tags show up as the latest since the major version is the highest. I would like to have cinder 2012.2 removed from PyPi since this version is surely useless at this point and to avoid any confusion (since there will likely will be enough of that if someone tries to just pip install cinder). Thanks! Sean
Sean, This looks like a good plan. I am in support. Jay On Mon, Mar 25, 2019, 10:56 AM Sean McGinnis <sean.mcginnis@gmx.com> wrote:
This is to make sure my request to infra is visible in case there are any concerns.
On PyPi we have a "2012.2" release of Cinder. Since our version numbering scheme changed to follow semver, these year-based version tags show up as the latest since the major version is the highest.
I would like to have cinder 2012.2 removed from PyPi since this version is surely useless at this point and to avoid any confusion (since there will likely will be enough of that if someone tries to just pip install cinder).
Thanks! Sean
Sean, This looks like a good plan. I am in support. Jay On Mon, Mar 25, 2019, 10:56 AM Sean McGinnis <sean.mcginnis@gmx.com> wrote:
This is to make sure my request to infra is visible in case there are any concerns.
On PyPi we have a "2012.2" release of Cinder. Since our version numbering scheme changed to follow semver, these year-based version tags show up as the latest since the major version is the highest.
I would like to have cinder 2012.2 removed from PyPi since this version is surely useless at this point and to avoid any confusion (since there will likely will be enough of that if someone tries to just pip install cinder).
Thanks! Sean
On 25/03, Sean McGinnis wrote:
This is to make sure my request to infra is visible in case there are any concerns.
On PyPi we have a "2012.2" release of Cinder. Since our version numbering scheme changed to follow semver, these year-based version tags show up as the latest since the major version is the highest.
I would like to have cinder 2012.2 removed from PyPi since this version is surely useless at this point and to avoid any confusion (since there will likely will be enough of that if someone tries to just pip install cinder).
Thanks! Sean
Yes, please. That made me think for a while that we were no longer publishing to PyPi.
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. -- Jeremy Stanley
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
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
participants (6)
-
Gorka Eguileor
-
Jay Bryant
-
Jay Bryant
-
Jeremy Stanley
-
Sean McGinnis
-
Tim Burke