Re: [PATCH] python-cffi: read version from notmuch version file

[Frank LENORMAND <lenormf.ml@gmail.com>]

On Wed Jun 24 00:16:35 2020, Floris Bruynooghe wrote:
> On Tue 23 Jun 2020 at 13:43 +0300, Frank LENORMAND wrote:
> > On Tue Jun 23 12:33:36 2020, David Bremner wrote:
> >> Frank LENORMAND <lenormf.ml@gmail.com> writes:
> >> > For example, 0.30.1, with the first two numbers coming from the main
> >> > repository, and the last one acting as major for the bindings.
> >> >
> >> > 0.29.3 → 0.29.1
> >> > 0.30-rc2 → 0.30.1-rc2
> >> > etc.
> >> >
> >> 
> >> I'm mainly interested in supporting two use cases for notmuch: building
> >> everything from source, and binary packages of released versions. We've
> >> already gone to some trouble to tell Emacs users that try to mix and
> >> match versions that they are on their own, and this seems to apply even
> >> more strongly to bindings users.
> >>    
> >> With that said, if Floris thinks some hierarchical version is useful,
> >> and is willing to maintain it, I can live with it. I would ask that:
> >> 
> >> 1) You keep the whole "upstream" version number. So the first example
> >> would be 0.29.3.1.  0.29.1 is a previous version of notmuch, and that
> >> ambiguity can only cause trouble.
> >
> > The idea was that the bindings will work with the X.Y version they were
> > released for, since the last component in X.Y.Z is for minor changes that
> > shouldn't affect the API.
> 
> Minor nitpicking, but API is not strong enough here, you'd need to
> ensure ABI compatibility.
> 
> > So we can keep X.Y from NotMuch itself, and append some information that
> > hint at the state of the bindings.
> [...]
> > Or the exact same version number, but then what should happen to it when
> > the bindings are modified, but not NotMuch?
> 
> If it was bad enough to need a new release then I guess everyone gets
> the same version bump as the entire project gets a bugfix release?
> 
> I honestly like the simplicity of just having the same version number
> and not having to think about maintaining it separately.  It also means
> we mostly don't have to worry about how setuptools/pip is going to view
> the version number.
> 
> The only way I think this could break is if we want to break backwards
> compatibility in the bindings, but we're not supposed to do that
> (realistically an impossible task in Python if you ask me, but we can
> aim for at least avoiding doing this knowingly).
> 
> The most likely version number sin is that the python bindings get a new
> feature while libnotmuch only gets bugfix.  I also don't think this is
> terrible, but that's perhaps unusual and frowned upon.  Maybe this
> warrants a README in the bindings to warn the version number just tracks
> libnotmuch and as far as python goes can only be used to order the
> releases.

Fair enough. I've never been in that situation before, so brainstorming
about it was fun :)

I'll keep an eye out for a patch.

Regards,
-- 
Frank LENORMAND