On Fri, Jun 1, 2012 at 8:17 PM, David Bremner <david at tethera.net> wrote: > Jameson Graef Rollins <jrollins at finestructure.net> writes: > >> I don't know, but this is one of the reasons I'm against having >> "contrib" stuff in the notmuch repo. ?If it's not part of the stuff >> we're willing to release in source tarballs or binary packages then it >> should probably be in a separate repo. > > Just to be clear, ./contrib currently is in the source tarballs, and at > least notmuch-mutt is included in a binary package for debian. > > I don't disagree that status is kindof odd, but I don't see the stuff in > contrib as being that different in practice from the bindings. In both > cases we have had incidences of bitrot. The python bindings are > currently not a problem, but both the ruby and go bindings stopped > working at all recently.
I see these as different issues: ruby bindings not working because of a change in the ruby bindings is understandable, but ruby bindings not working because of an API change *and* that nobody bothered to implement this change would not make sense to me. Maybe ruby maintainers don't have that much time, which is why they don't make so many changes; but the bindings still work, and if somebody has the time to make changes, well, he has the time, but forcing the issue when breaking API does not make sense. I don't see why it would be difficult to do the API updates through all the notmuch code; if we can't update the API through all the code in a timely manner, how do we hope 3rd party uses would? If anything it would be an incentive to don't break the API so often; let's face it, notmuch is not so widely used, and breaking the API is not going to help things. Another option is to go the FFmpeg way: create a new function notmuch_database_open2, mark the old one as deprecated (but still works), and only after some time obsolete it. Cheers. -- Felipe Contreras