On 11/26/2014 09:29 AM, Ben Finney wrote: > Howdy, > > You are maintaining a package with a dependency on ‘python-lockfile’. > That package will soon upgrade to a backward-incompatible version, and > dependent packages need to accommodate this compatibility breakage. > > 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. > > As I see it, there are several actions to take: > > * Upload a new version of your package which declares a versioned > dependency on “python-lockfile (<< 0.9)” to make the API > incompatibility explicit. > > This informs the dependency manager that the package only works with > older ‘python-lockfile’ versions, and means the package cannot be > installed with a newer ‘python-lockfile’. > > * Work with your package's upstream to have the code support > ‘lockfile’'s current API, if it doesn't already. Encourage them to > release a new version with that support. > > * Package the new version in Debian, declaring a dependency on > “python-lockfile (>= 0.9)”. > > If you've already done this, great! Please let me know so that I can > keep track of which packages are affected. > > I intend to release ‘python-lockfile’ at version 0.9 or later. I would > prefer to have dependent packages ready for this API change. If you > need help, please ask.
I'm sorry, but aren't we in the deep freeze phase of Jessie? What's your plan exactly? Release a new package in Debian Experimental? Even if you do that, I don't think it's a good idea to do it now. People (like me) are uploading to Experimental because they can't do it in Sid, so having a new package in there may break things. Can't you update lockfile after the release of Jessie? Also, could you give a brief sum-up of the API breakage between <<9 and >= 9? 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 in a small 500 lines library containing only 12 classes and 26 methods, while the Linux kernel (which is far more complex) doesn't break the userland at all, as a rule. 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? Cheers, Thomas Goirand (zigo) _______________________________________________ Python-modules-team mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
