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 _______________________________________________ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch