Issue #1246
closed
UnitPublishStep incompatibility in 2.5 and 2.6
Description
I noticed there's missing working_dir attribute in init of UnitPublishStep in pulp-2.6. UnitPublishStep is descendant of PublishStep which has this attribute.
Then, working_dir will be always None and get_working_dir() will always fetch it from repo configuration.
So if I have working plugin (and I have one) that uses UnitPublishStep in 2.5, it means I have to rewrite it for 2.6.
Is there any specific reason for breaking API compatibility?
Updated by mhrivnak over 8 years ago
- Status changed from NEW to CLOSED - WONTFIX
There is no reason except that this area of code is so new that we haven't been able to offer or maintain API compatibility yet. I assure you we want to and are moving that direction.
Since both of these versions are already released, we can't change it back at this point.
Updated by bmbouter over 8 years ago
jluza: For future releases testing your plugin against a beta and/or RC would be really great. That would help us spot these incompatibilities pre-release.
Updated by dgregor@redhat.com over 8 years ago
Please reconsider this. The API compatibility can be maintained by adding working_dir as an optional attribute to the UnitPublishStep init method.
Regarding the comment about testing beta and/or RC... yes, that would be great and we want to do that. However, it shouldn't fall on users of Pulp to detect API changes.
Updated by mhrivnak over 8 years ago
The specific code in question is not yet part of a public API. We are not advertising or guaranteeing any level of compatibility from one release to the next. Any assumption to the contrary is incorrect.
Long-term, we would like to turn this area of code into a more formal API whose changes are carefully tracked and documented. However right now, this is just a library of generic plugin code that we use for our own benefit to make plugin development easier. Since we use this code in a lot of places, we try not to make backward-incompatible changes, because we have to update all of those places.
The overall design of this code is young and still evolving. Establishing it as a stable API is desired, but not a priority. We invite and encourage all plugin developers to use this code with us, because we believe it will make plugin writing easier and more consistent. But some amount of change is to be expected.
Since 2.6 was already released some time ago, changing how this code works now would only make the situation worse. Since you are advocating for more stability in this area of code, I am sure you can appreciate why we don't want to change the behavior in a Z release.
Updated by bmbouter almost 4 years ago
- Category deleted (
14)
We are removing the 'API' category per open floor discussion June 16, 2020.
.