Hi,
In a recent issue, Chris proposed to factor out part of the
code base into a stand-alone CPAN release (which would IMO
mean into a more-or-less stand alone project). The same
happened some years ago when he factored out DBObject into
PGObject, so, we have precedence here. The other way around
(refactored our code to use releases from CPAN) has happened
as well.
From my perspective, the reasons to refactor our code to
make use of (pre-existing) CPAN code are clear:
* Using pre-existing code from CPAN outsources maintenance
(to an external maintainer)
* Opens up opportunities for wider use in our own code
base, because usually replaces specific with generic code
* Ensures better testing of code in a wide variety of
settings (hopefully with bugfixes)
* Improves code-sharing in the wider Perl community
(hopefully free-ing up resources to take Perl and its modules
a step further)
To me, the other way around would roughly work the same
way. Meaning, that we should be thinking about placing our
code on CPAN, if:
* Our code is sufficiently generic to solve problems for
others
* Others can depend on us to do the maintenance of the
code
* Our code comes with sufficient quality assurance
measures to be helpful to others
* Our code is sufficiently stable not to require large
refactorings to the projects (which would mean that people
can't really depend on the code - yet)
Especially the last point - I think - is tricky: when
largish refactorings are in order, the fact that part of the
code being refactored is loaded onto Travis CI through CPAN is
a major limitation on the speed that can be had during the
refactoring. The recent PGObject 1.x->PGObject 2.x
refactoring showed that.
I'm wondering: Is there anything else to be considered?
(Reasons to factor out, problems to be met after having
separated, etc...)
Regards,
--
Bye,
Erik.
Robust and Flexible. No vendor lock-in.
