Can't compile notmuch-delivery

[Felipe Contreras]

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