On 26-Nov-2014, Thomas Goirand wrote: > On 11/26/2014 09:29 AM, Ben Finney wrote: > > The ‘lockfile’ upstream changed the API as of version 0.9 > > <URL:https://code.google.com/p/pylockfile/source/browse/trunk/RELEASE-NOTES>, > > and dependent Python code will not work until it uses the current API. > > Would it be possible to work with upstream to avoid such breakage? > It doesn't seem reasonable at all to me to have API breakage It isn't good, I agree. I did work with the upstream at that time, and they did attempt to address this (incrementing the minor version, providing factory functions), but I was unaware the API breakage was planned until a new version was already released. > I believe it's our role as a distribution to work with upstream to > avoid such craziness. Maybe upstream doesn't understand the > importance of a stable API, and it would be worth explaining how bad > such breakage is. What is your view here? I agree with all that. I did attempt to educate upstream about the importance of providing an upgrade path, but it wasn't enough in this case. It's very difficult to get most upstream Python developers to care much about API stability, especially in a culture where “install everything into a virtualenv and ignore the OS package manager” is the normal mode of thinking. I'd love all Python library upstreams to take <URL:https://wiki.debian.org/UpstreamGuide> to heart, but the current reality is that most do not at this time. May the education campaign continue; in the meantime, I need package maintainers to help clean up that mess. -- \ “Technology is anything that wasn't around when you were born.” | `\ —Alan Kay | _o__) | Ben Finney <ben@benfinney.id.au>
Attachment:
signature.asc
Description: Digital signature