Perl module development - managing branches

[Bill Moseley]

I'm looking for ideas to manage our in-house Perl distributions when
working with different branches.   I'm wondering if anyone here has been
though this before and has some suggestions.

We are in the process of moving from Subversion to Git and the plan is to
make all changes to the code in branches and use pull requests into the
release Git repo. Similar to "gitflow" workflow.

What we have been doing up until now is running our own private CPAN
(DarkPAN) where developers release updated distributions.   For branching
we have at time used multiple DarkPANs, but that has been rare.   We have
also looked extensively at Pinto, which is designed specifically for this,
but so far using multiple DarkPANs has worked when needed.

Our old process followed the CPAN model.   We had all our Perl
distributions in svn and once changes were checked in and tested then the
developer would "release" to our internal DarkPAN.  That would generate a
new version (using Dist::Zilla) and then code would depend on that version:
 "use MyCorp::Foo 1.142300;

The idea, of course, is that the new version of a module is backwards
compatible.  So, keeping the most recent version in a common DarkPAN was
fine.    That's not always the case when branching and incorporating code
at different times.   The root of the problem is we need to have parallel
branches and version numbers are not branch-aware.

Our current thought is to throw out version numbers and the idea of
dependencies.  Each branch would contain ALL our in-house distributions and
we would build all the distributions and install into Perlbrew at build
time.     But, then how do developer's work?

Here's a few sticking points:

   - All the modules need to be in @INC -- so we might have to create
   symlinks to each  distribution's "lib" directory.
   - But, some code is XS or uses share directories.
   - Some modules don't exist until "make" is run -- they are created when
   the module is build.

Is this situation familiar to anyone?   Have you found an approach that
works well?

Thanks,



-- 
Bill Moseley
moseley at hank.org