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@ubuntu:~$ pip freeze | grep networking-hyperv > > (test) ubuntu@ubuntu:~$ pip install networking-hyperv > ... > (test) ubuntu@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
