Re: [ledgersmb-devel] Setting a policy for our dependencies

For that specific point, I'm against requiring that for 1.5 and lower but in master we restricted PGObject for a while with ''>=1.403002, < 2''.

Yes. We did that to suppress the warnings that the PGObject code was generating. Later it wasn't PGObject anymore generating these warnings, but PGObject-Type-DateTime was. All these warnings were fixed, so, there's no reason to keep the upperbound anymore. Each version as of 1.403.2 (=1.403002) will work (except for PGObject 2.0.0 which I remember to have a bug which broke our use)

Now do we want to keep that and make it '>=1.403002, < 2' or '>=2.000200'?

Yes.

Where will that lead us?

Currently 1.403.2 is packaged in Debian. So, that provides us Debian Jessie & Stretch backward compatibility.

How much time do we want to maintain backward compatibility for a package for which we are close to be the only user?

We may be the only *user* of the module, but not the only packager or installer. Some people (quite many, actually) rather would not use local::lib for their installations, but use the distribution's package archive.

Yves

Le 2017-08-27 à 17:52:51, Erik Huelsmann a écrit :

Hi,

Of course we aren't there yet but I would suggest that a forward-thinking view of dependencies we might want to think about it not only regarding the dependency problems we encounter with maintaining and working on the current code but also in the question of how modularised and loosely coupled we may want the code to be in the future.

My approach here has been to put the problem of dependency declaration in a system with loosely coupled components is to be part of a design of such a module system; that is, for now, I haven't been looking too far into the future and trying to make the best out of the current situation for current package managers and installers-from-source. The immediate trigger for my previous mail was a discussion on #ledgersmb with Yves and David about the fact that Yves declared the minimum version of PGObject to be 2.0.2. I'm against requiring such a new version as the bare minimum since the code base supports anything at or newer than 1.403.2. Hence my idea about requiring a policy with a solid reasoning of why we do things the way we do. Then we also have a good foundation to evaluate the minimum PGObject version requirement.

Regards,

--

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.