Open Stack

Excerpts from Claudiu Belu's message of 2017-08-29 14:09:32 +0000:
> Hello,
> 
> As many of you know, during Kilo, the neutron vendor decomposition happened, which lead to the birth of many networking-* libraries, including networking-hyperv. When it was time for us to make a release for that cycle, pretty much every networking-* project followed the release version number at that time, which was 2015.1.0. After Kilo, the versioning changed to the current format.
> 
> networking-hyperv currently contains the "hyperv" mechanism_driver, which is needed in order to bind neutron ports to Hyper-V compute nodes using neutron-hyperv-agent L2 agents.
> 
> Now, my main issue is that networking-hyperv==2015.1.0 is currently on Pypi, and whenever someone upgrades networking-hyperv through pip (pip install -U networking-hyperv), it "upgrades" to 2015.1.0. And even if it isn't already installed, networking-hyperv==2015.1.0 is installed, as that is considered the "latest" version:
> 
> (test) ubuntu at ubuntu:~$ pip freeze | grep networking-hyperv
> 
> (test) ubuntu at ubuntu:~$ pip install networking-hyperv
> ...
> (test) ubuntu at ubuntu:~$ pip freeze | grep networking-hyperv
> networking-hyperv==2015.1.0
> 
> This is a common pitfall for people using pip to install / upgrade networking-hyperv. It's actually become a ritual for new developers to mistakenly install the "latest" version. :)
> 
> Now, my question is: could we / should we unpublish the 2015.1.0 version?
> 
> [1] Kolla using pip package "networking-hyperv>=5.0.0,<6.0.0"  https://review.openstack.org/#/c/498409/1
> [1] #openstack-release: http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2017-08-29.log.html#t2017-08-29T08:19:28
> [2] #openstack-release: http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2017-08-29.log.html#t2017-08-29T13:20:36
> 
> 
> Best regards,
> 
> Claudiu Belu

Thierry mentioned in #openstack-release that this issue did come
up when we originally changed to using SemVer. However, at that
time we only had service projects using date-based versions and we
did not support installing those from PyPI. Distribution packages
updated their epoch setting, which allowed them to reset the rest
of the version number to an apparently lower value and still have
it considered as newer.  Python packaging doesn't have that sort
of ability, unfortunately.

If that 2015 version is no longer maintained, then deleting it from
PyPI may be the most effective way to avoid this particular support
issue, even though that is normally not something we recommend.

Doug