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,
--
Bye,
Erik.
Robust and Flexible. No vendor lock-in.