MIME-Version: 1.0
In-Reply-To: <874nqu28y1.fsf@zancas.localnet>
References: <20120531214259.GA18272@desktop>
	<m2pq9jo7jf.fsf@guru.guru-group.fi>
	<CAMP44s0vvEDLd2DceFraNpqyMrX2A+=zkV6W=ABatZs52FNo5Q@mail.gmail.com>
	<87lik7171d.fsf@zancas.localnet>
	<87sjefufub.fsf@servo.finestructure.net>
	<874nqu28y1.fsf@zancas.localnet>
Date: Fri, 1 Jun 2012 20:44:16 +0200
Message-ID:
 <CAMP44s3mHg_bF154QTtMFqs1rx7SLhuZXwsXYScF6bKgcdK5Ag@mail.gmail.com>
Subject: Re: Can't compile notmuch-delivery
From: Felipe Contreras <felipe.contreras@gmail.com>
To: David Bremner <david@tethera.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Tomi Ollila <tomi.ollila@iki.fi>, Ali Polatel <alip@exherbo.org>,
	notmuch@notmuchmail.org
Precedence: list

On Fri, Jun 1, 2012 at 8:17 PM, David Bremner <david@tethera.net> wrote:
> Jameson Graef Rollins <jrollins@finestructure.net> writes:
>
>> I don't know, but this is one of the reasons I'm against having
>> "contrib" stuff in the notmuch repo. =C2=A0If 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.

--=20
Felipe Contreras