Setting a policy for our dependencies
Hi,
Sending this mail to the mailing list, because I think that's where we need to set our policies.
I'm starting this topic because I feel like it's come up several times now and I think it's time to set a policy, with documented reasons as to why we're working the way we do.
First, let me re-iterate what I think are our shared goals for LedgerSMB (as related to our choice of dependencies). We want:
LedgerSMB to be easy to install, meaning * On as many platforms as possible * Allowing people to use their distro's packages as much as possible * Running first and foremost on Perl versions in most distros * Allowing for a wide range of PostgreSQL versions * Integrating (through PSGI/reverse-proxy) with people's favorate webserver
Translating the above into requirements for modules we depend on, I think we want to:
* Use modules which have been around for a while (to increase chances of being packaged) * Allow the widest possible version range on any module, disallowing individual malfunctioning versions to further extend the range * Require as few a possible modules in the expanded dependency tree (prefer modules as direct dependencies which are already depended on implicitly) * Not depend directly on modules which have overlapping functionalities * Not require modules which only provide nice-to-have functionality * Group feature dependencies into their respective features as much as possible (so as to not require them for a more basic installation)
With respect to modules used in development, I'd like to be less strict, but only marginally so: we want it to be "simple enough" to create a development setup for LedgerSMB.
Comments?
Regards,
participants (1)
-
Erik Huelsmann