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 [email protected]
