The foundation for your business
Fork me on GitHub
Re: [ledgersmb-devel] Setting a policy for our dependencies
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


For that specific point, I'm againt requiring that for 1.5 and lower but in master we restricted PGObject for a while with ''>=1.403002, < 2''. Now do we want to keep that and make it '>=1.403002, < 2' or '>=2.000200'? Where will that lead us? How much time do we want to maintain backward compatibility for a package for which we are close to be the only user?


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

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.

devel mailing list