Pulp

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.

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.

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.