Release 0.18 included backward incompatible change which breaks one OpenStack component https://bugs.launchpad.net/ironic-python-agent/+bug/1522756 Issue was reported upstream: https://github.com/pyudev/pyudev/issues/129 While at it, would be nice to persuade upstream to switch to semver :)
Don't do anything, you say? I'll get right on it ;-) Thanks for the heads up.
> Don't do anything, you say? Implicit message was: try to influence upstream :)
But the change _is_ backwards compatible, as the original reporter has now figured out. See issue discussion: https://github.com/pyudev/pyudev/issues/129.
The changes is not backward compatible. I know the work around now, yes, but it does not mean that working code won't break. It would be compatible only if new exception class was derived from old one, as I suggested initially.
You have finally fixed a bug that has been in your code since you first started using the method from_device_file(). This method transitively invokes the method from_device_number() which may raise DeviceNotFoundByNumberError which is a subtype of DeviceNotFoundError. This error, if raised, is propagated and should be caught by any code that invokes from_device_file(). All you need to do is fix your code to catch DeviceNotFoundError, like you should have been doing all along. If anything, this is an ironic_python_agent bug and should be treated as such.
You're free to close this bug, if you don't care too much about other consumers of your library who might have hit by it, I won't reopen, but please stop assigning it to random projects. python-ironicclient is not involved here at all. And as you noted, IPA was fixed to work around the break. Also this: > All you need to do is fix your code to catch DeviceNotFoundError, like you should have been doing all along. You code has never raised DeviceNotFoundError, we should NOT have caught it before the change. Again, feel free to close it, but don't blame others for your actions please.
First, it is not my code, it is Sebastian Werner's, principally. Second, that your tests haven't caused that exception to be raised just means that your tests are not complete enough. The code has always been capable of raising that error. Third, except for a physics post-doc in Germany and one Red Hat employee who has contributed a bug fix the main thing my downstream consumers have contributed is insults. "Caring" does not come naturally to anybody in that situation, it's not a very "caring" environment. Fourth, according to the document that you sent me: http://semver.org/, "Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable." If you understand semantic versioning, then you understand that version 0.17 means that the API can change at any time. Any of the _hard_ work that I do to keep the API stable is not in any way an obligation by these semantic versioning standards which you claim I'm breaking. Fifth, the only reason to keep the API stable is professional pride, consideration of clients, and the good of Red Hat, which pays my salary. Red Hat does not pay me to waste my time in this kind of pointless argument. I assume it doesn't pay you for that, either.