Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
On 2017-09-29 17:31:10 +0200 (+0200), Thierry Carrez wrote: > OK, I got individual PTL confirmation that it was OK to remove all of > those from PyPI: > > mistral-extra 2015.1.0 > mistral-dashboard 2015.1.* > > networking-odl, 2015.1.1 2015.1.dev986 > > networking-midonet, 2014.2.2 and various 2015.1.* versions > (might have been removed by networking-midonet folks by now) > > sahara-image-elements 2014.*.* > sahara-dashboard 2014.*.* I finally got around to processing these deletions. And yes as far as I can tell someone with access to the "midonet" account on PyPI already took care of the networking-midonet cleanup, but I've handled the others now. -- Jeremy Stanley signature.asc Description: Digital signature __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
OK, I got individual PTL confirmation that it was OK to remove all of those from PyPI: mistral-extra 2015.1.0 mistral-dashboard 2015.1.* networking-odl, 2015.1.1 2015.1.dev986 networking-midonet, 2014.2.2 and various 2015.1.* versions (might have been removed by networking-midonet folks by now) sahara-image-elements 2014.*.* sahara-dashboard 2014.*.* Cheers, -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
I confirm that you can delete mistral versions with “2015”. Thanks Renat Akhmerov @Nokia On 15 Sep 2017, 23:58 +0700, Rong Zhu , wrote: > +1 for murano-dashboard and murano-agent > > On Fri, Sep 1, 2017 at 1:51 AM, Thierry Carrez wrote: > > Claudiu Belu wrote: > > > So, I believe the general consensus is that the easiest thing to do is to > > > unpublish the 2015.1.0 version from pypi, with which I also agree. > > > [...] > > > > Yes, for a first batch I propose we clean up the following: > > > > python-congressclient 2015.1.0 > > python-congressclient 2015.1.0rc1 > > python-designateclient 2013.1.a8.g3a2a320 > > networking-hyperv 2015.1.0 > > > > For the remaining (official) ones (mistral-extra, networking-odl, > > murano-dashboard, networking-hyperv, networking-midonet, > > sahara-image-elements, freezer-api, murano-agent, mistral-dashboard, > > sahara-dashboard) let's wait until we can get PTL signoff. > > > > -- > > Thierry Carrez (ttx) > > > > __ > > 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 > > __ > 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 __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
+1 for murano-dashboard and murano-agent On Fri, Sep 1, 2017 at 1:51 AM, Thierry Carrez wrote: > Claudiu Belu wrote: >> So, I believe the general consensus is that the easiest thing to do is to >> unpublish the 2015.1.0 version from pypi, with which I also agree. >> [...] > > Yes, for a first batch I propose we clean up the following: > > python-congressclient 2015.1.0 > python-congressclient 2015.1.0rc1 > python-designateclient 2013.1.a8.g3a2a320 > networking-hyperv 2015.1.0 > > For the remaining (official) ones (mistral-extra, networking-odl, > murano-dashboard, networking-hyperv, networking-midonet, > sahara-image-elements, freezer-api, murano-agent, mistral-dashboard, > sahara-dashboard) let's wait until we can get PTL signoff. > > -- > Thierry Carrez (ttx) > > __ > 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 __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
On 2017-09-07 08:59:15 +0200 (+0200), Thierry Carrez wrote: > Jeremy Stanley wrote: > > On 2017-09-01 09:51:36 +0200 (+0200), Thierry Carrez wrote: > > [...] > >> Yes, for a first batch I propose we clean up the following: > >> > >> python-congressclient 2015.1.0 > >> python-congressclient 2015.1.0rc1 > >> python-designateclient 2013.1.a8.g3a2a320 > >> networking-hyperv 2015.1.0 > > [...] > > > > Are we waiting for any confirmation on this, or does a week of > > silence constitute tacit approval? Should I go ahead and delete > > these from PyPI now? > > Yes please. I have removed the above releases from PyPI as requested. Releases made through our CI builds can still be found on https://tarballs.openstack.org/ if needed in the future, even if deleted from PyPI. -- Jeremy Stanley signature.asc Description: Digital signature __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
Jeremy Stanley wrote: > On 2017-09-01 09:51:36 +0200 (+0200), Thierry Carrez wrote: > [...] >> Yes, for a first batch I propose we clean up the following: >> >> python-congressclient 2015.1.0 >> python-congressclient 2015.1.0rc1 >> python-designateclient 2013.1.a8.g3a2a320 >> networking-hyperv 2015.1.0 > [...] > > Are we waiting for any confirmation on this, or does a week of > silence constitute tacit approval? Should I go ahead and delete > these from PyPI now? Yes please. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
On 2017-09-01 09:51:36 +0200 (+0200), Thierry Carrez wrote: [...] > Yes, for a first batch I propose we clean up the following: > > python-congressclient 2015.1.0 > python-congressclient 2015.1.0rc1 > python-designateclient 2013.1.a8.g3a2a320 > networking-hyperv 2015.1.0 [...] Are we waiting for any confirmation on this, or does a week of silence constitute tacit approval? Should I go ahead and delete these from PyPI now? -- Jeremy Stanley signature.asc Description: Digital signature __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
networking-hyperv is under the Winstackers governance [1], of which I am the PTL of, and you have my +1. :) [1] http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml#n4656 From: Thierry Carrez [thie...@openstack.org] Sent: Friday, September 01, 2017 10:51 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [relmgt] Libraries published to pypi with .X.Z versions Claudiu Belu wrote: > So, I believe the general consensus is that the easiest thing to do is to > unpublish the 2015.1.0 version from pypi, with which I also agree. > [...] Yes, for a first batch I propose we clean up the following: python-congressclient 2015.1.0 python-congressclient 2015.1.0rc1 python-designateclient 2013.1.a8.g3a2a320 networking-hyperv 2015.1.0 For the remaining (official) ones (mistral-extra, networking-odl, murano-dashboard, networking-hyperv, networking-midonet, sahara-image-elements, freezer-api, murano-agent, mistral-dashboard, sahara-dashboard) let's wait until we can get PTL signoff. -- Thierry Carrez (ttx) __ 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 __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
Claudiu Belu wrote: > So, I believe the general consensus is that the easiest thing to do is to > unpublish the 2015.1.0 version from pypi, with which I also agree. > [...] Yes, for a first batch I propose we clean up the following: python-congressclient 2015.1.0 python-congressclient 2015.1.0rc1 python-designateclient 2013.1.a8.g3a2a320 networking-hyperv 2015.1.0 For the remaining (official) ones (mistral-extra, networking-odl, murano-dashboard, networking-hyperv, networking-midonet, sahara-image-elements, freezer-api, murano-agent, mistral-dashboard, sahara-dashboard) let's wait until we can get PTL signoff. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
So, I believe the general consensus is that the easiest thing to do is to unpublish the 2015.1.0 version from pypi, with which I also agree. Even if someone actually needs the Kilo version (it's a very old branch, very few people still use it, at most), it can still be done via [1]: pip install git+http://github.com/openstack/networking-hyperv@2015.1.0#networking-hyperv or pip install http://tarballs.openstack.org/networking-hyperv/networking_hyperv-2015.1.0-py2-none-any.whl If someone *actually* needs it on pypi, We could publish a 0.x.y version, but I don't think it will be necessary. Also, @Tony, using upper-constraints wouldn't work when installing networking-hyperv won't really help, as it isn't defined there. networking-hyperv is not a requirement in any project, it's only needed by neutron if the "hyperv" mechanism_driver is used. Thanks @all for your opinions! Best regards, Claudiu Belu From: Jeremy Stanley [fu...@yuggoth.org] Sent: Thursday, August 31, 2017 3:05 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [relmgt] Libraries published to pypi with .X.Z versions On 2017-08-31 15:21:19 +1000 (+1000), Tony Breeds wrote: [...] > I assume it's infra that needs to do the actual unpublish? We're the ones with the most consistent access to all of them, though in a majority of cases there's at least one other account with sufficient access to do the same (it just tends to vary by team and origination timeframe). So, yes, probably easiest to give the Infra team a list once it's been confirmed. -- Jeremy Stanley __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
On 2017-08-31 15:21:19 +1000 (+1000), Tony Breeds wrote: [...] > I assume it's infra that needs to do the actual unpublish? We're the ones with the most consistent access to all of them, though in a majority of cases there's at least one other account with sufficient access to do the same (it just tends to vary by team and origination timeframe). So, yes, probably easiest to give the Infra team a list once it's been confirmed. -- Jeremy Stanley signature.asc Description: Digital signature __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
On Wed, Aug 30, 2017 at 05:04:58PM +0200, Thierry Carrez wrote: > Tony Breeds wrote: > > An extension to this would be to check for other items in the same boat. > > I wrote [1] to find anything in the openstack namespace that isn't a > > service and has something that looks like a date based release on pypi. > > [...] > > Thanks for computing the list. Unpublishing is a bit of a trade-off -- > in the networking-hyperv case the pain resulting from the people using > pip to install it (and complaining about the situation) ends up being > bigger than the pain of unpublishing it... So I'm not sure we should > necessarily proactively unpublish everything in the same boat > (especially if nobody asks for it). In particular, we should definitely > *not* do it for anything that's not an official OpenStack deliverable. Okay I could tweak the tool to only check for repos that are in openstack/governance:reference/projects.yaml but it looks like you've already done that translation in your head ;P > That leaves us with: > > Official libraries (python-congressclient, python-designateclient) for > which I think we should proactively fix them ASAP. > > Other official things (mistral-extra, networking-odl, murano-dashboard, > networking-hyperv, networking-midonet, sahara-image-elements, > freezer-api, murano-agent, mistral-dashboard, sahara-dashboard) for > which we should fix them if pip is a reasonable way of installing them > (after asking the local PTL if that's alright). Cool. If we don't get any traction here can use the PTG to find PTLs ;P I assume it's infra that needs to do the actual unpublish? Yours Tony. signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
Tony Breeds wrote: > An extension to this would be to check for other items in the same boat. > I wrote [1] to find anything in the openstack namespace that isn't a > service and has something that looks like a date based release on pypi. > [...] Thanks for computing the list. Unpublishing is a bit of a trade-off -- in the networking-hyperv case the pain resulting from the people using pip to install it (and complaining about the situation) ends up being bigger than the pain of unpublishing it... So I'm not sure we should necessarily proactively unpublish everything in the same boat (especially if nobody asks for it). In particular, we should definitely *not* do it for anything that's not an official OpenStack deliverable. That leaves us with: Official libraries (python-congressclient, python-designateclient) for which I think we should proactively fix them ASAP. Other official things (mistral-extra, networking-odl, murano-dashboard, networking-hyperv, networking-midonet, sahara-image-elements, freezer-api, murano-agent, mistral-dashboard, sahara-dashboard) for which we should fix them if pip is a reasonable way of installing them (after asking the local PTL if that's alright). -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital signature __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
On 17-08-29 15:58:55, Jeremy Stanley wrote: > On 2017-08-29 10:30:42 -0500 (-0500), Matthew Thode wrote: > [...] > > 3. reversion. Start new versions at 3000 or something, kinda > > dirty imo. > > And sort of a 3.1 option is to prepend a PEP 440 version epoch: > > https://www.python.org/dev/peps/pep-0440/#version-epochs > > Challenge there is that, while Git can handle a ! in a tag name, PBR > doesn't know to sort that after implicit 0 epochs nor does a lot of > our release automation have the ability to cope with version epochs > and adding support for them would entail a lot of careful work and > thorough testing. Also having upstream epochs could wreak havoc with > downstream distro package maintainers, look confusing in > tarball/wheel filenames (hopefully all modern platforms are at least > not going to break when there's a ! in a filename), and so on. > > The concerns were touched on in this thread from 2015 when the > versioning changes were going into effect: > > http://lists.openstack.org/pipermail/openstack-dev/2015-July/069085.html > > Pretty unlikely to happen if you ask me. I'm just bringing it up > preemptively since odds are someone else with less history/memory of > the scenarios we discussed back then is likely to bring it up as a > silver bullet solution otherwise. > -- > Jeremy Stanley I almost mentioned that, but as you said, the barrier to entry there is so high. -- Matthew Thode signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
On Tue, Aug 29, 2017 at 02:09:32PM +, Claudiu Belu wrote: > (test) ubuntu@ubuntu:~$ pip freeze | grep networking-hyperv > > (test) ubuntu@ubuntu:~$ pip install networking-hyperv I know this isn't a solution but I'd be remiss if I didn't point it out: uc_url=https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt pip install -c "$uc_url" networking-hyperv will do the right thing > 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? Seems like that's the best thing to do. An extension to this would be to check for other items in the same boat. I wrote [1] to find anything in the openstack namespace that isn't a service and has something that looks like a date based release on pypi. Clearly this is a very rough check but it looks like potentially have a few things we could clean up, the hard part is working with the affected projects teams to decide the correct action. --- python-congressclient has 2015.1.0 which might need to be unpublished python-congressclient has 2015.1.0rc1 which might need to be unpublished group-based-policy has 2015.1.1 which might need to be unpublished group-based-policy has 2014.2.1 which might need to be unpublished group-based-policy has 2015.1.3 which might need to be unpublished group-based-policy has 2015.1.0b1 which might need to be unpublished group-based-policy has 2014.2.10 which might need to be unpublished group-based-policy has 2015.2.7 which might need to be unpublished group-based-policy has 2015.2.4 which might need to be unpublished group-based-policy has 2015.2.5 which might need to be unpublished group-based-policy has 2015.2.2 which might need to be unpublished group-based-policy has 2015.2.3 which might need to be unpublished group-based-policy has 2015.2.0 which might need to be unpublished group-based-policy has 2015.2.1 which might need to be unpublished group-based-policy has 2015.1.0b2 which might need to be unpublished group-based-policy has 2015.2.8 which might need to be unpublished group-based-policy has 2015.1.7 which might need to be unpublished group-based-policy has 2014.2rc1 which might need to be unpublished group-based-policy has 2015.1.0 which might need to be unpublished group-based-policy has 2014.2rc3 which might need to be unpublished group-based-policy has 2014.2rc2 which might need to be unpublished group-based-policy has 2015.1.5 which might need to be unpublished group-based-policy has 2015.1.4 which might need to be unpublished group-based-policy has 2015.1.6 which might need to be unpublished group-based-policy has 2015.1.9 which might need to be unpublished group-based-policy has 2015.1.8 which might need to be unpublished group-based-policy has 2014.2.0rc1 which might need to be unpublished group-based-policy has 2014.2.4 which might need to be unpublished group-based-policy has 2014.2.7 which might need to be unpublished group-based-policy has 2014.2.6 which might need to be unpublished group-based-policy has 2014.2.5 which might need to be unpublished group-based-policy has 2014.2.3 which might need to be unpublished group-based-policy has 2014.2.2 which might need to be unpublished group-based-policy has 2014.2.8 which might need to be unpublished group-based-policy has 2015.1.2 which might need to be unpublished group-based-policy has 2014.2.9 which might need to be unpublished group-based-policy has 2014.2 which might need to be unpublished mistral-extra has 2015.1.0 which might need to be unpublished networking-fujitsu has 2015.1.1 which might need to be unpublished networking-fujitsu has 2015.1.0 which might need to be unpublished networking-fujitsu has 2015.2.0.dev7 which might need to be unpublished networking-fujitsu has 2015.2.0 which might need to be unpublished cloudpulse has 2016.1.1 which might need to be unpublished cloudpulse has 2015.3.1 which might need to be unpublished cloudpulse has 2015.2.6 which might need to be unpublished cloudpulse has 2015.3.2 which might need to be unpublished cloudpulse has 2015.2.4 which might need to be unpublished cloudpulse has 2015.2.5 which might need to be unpublished cloudpulse has 2015.2.3 which might need to be unpublished cloudpulse has 2015.3.3 which might need to be unpublished networking-odl has 2015.1.1 which might need to be unpublished networking-odl has 2015.1.dev986 which might need to be unpublished murano-dashboard has 2015.1.0b1 which might need to be unpublished murano-dashboard has 2015.1.0b3 which might need to be unpublished murano-dashboard has 2015.1.0b2 which might need to be unpublished murano-dashboard has 2015.1.1 which might need to be unpublished murano-dashboard has 2015.1.0 which might need to be unpublished murano-dashboard has 2015.1.0rc1 which might need to be unpublished murano-dashboard has 2014.2
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
On 2017-08-29 18:26:49 +0200 (+0200), Thierry Carrez wrote: [...] > Yeah, in that specific case I think that's the simplest route. It's not > really destroying it, it just prevents PyPI from erroneously > distributing it, without having to add a PEP440-Epoch to an OpenStack > deliverable and discovering all the bugs that it would trigger. Agreed, we even still make it available from tarballs.openstack.org in case someone doesn't want to have to try and rebuild it from the tag. -- Jeremy Stanley signature.asc Description: Digital signature __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
Doug Hellmann wrote: > 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. Yeah, in that specific case I think that's the simplest route. It's not really destroying it, it just prevents PyPI from erroneously distributing it, without having to add a PEP440-Epoch to an OpenStack deliverable and discovering all the bugs that it would trigger. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
On 2017-08-29 10:30:42 -0500 (-0500), Matthew Thode wrote: [...] > 3. reversion. Start new versions at 3000 or something, kinda > dirty imo. And sort of a 3.1 option is to prepend a PEP 440 version epoch: https://www.python.org/dev/peps/pep-0440/#version-epochs Challenge there is that, while Git can handle a ! in a tag name, PBR doesn't know to sort that after implicit 0 epochs nor does a lot of our release automation have the ability to cope with version epochs and adding support for them would entail a lot of careful work and thorough testing. Also having upstream epochs could wreak havoc with downstream distro package maintainers, look confusing in tarball/wheel filenames (hopefully all modern platforms are at least not going to break when there's a ! in a filename), and so on. The concerns were touched on in this thread from 2015 when the versioning changes were going into effect: http://lists.openstack.org/pipermail/openstack-dev/2015-July/069085.html Pretty unlikely to happen if you ask me. I'm just bringing it up preemptively since odds are someone else with less history/memory of the scenarios we discussed back then is likely to bring it up as a silver bullet solution otherwise. -- Jeremy Stanley signature.asc Description: Digital signature __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
Excerpts from Claudiu Belu's message of 2017-08-29 14:09:32 +: > 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
On 17-08-29 14:09:32, Claudiu Belu wrote: > 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 > > __ > 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 I think we have three options here. 1. Unpublish. This is probably the simplest, but generally goes against the policy of pypi to never unpublish things (it is not a hard and fast rule though). 2. Rename. A bunch of work for downstreams but technically cleaner/better than unpublishing, allows a more consistant naming scheme to be used if desired at least. 3. reversion. Start new versions at 3000 or something, kinda dirty imo. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature __ 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
[openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
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 __ 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