Credit: https://medium.com/xebia-engineering/branching-and-release-strategies-119e60241345

Before I jump into a bit of a rant about versions of things, I should mention that this is my first post to my new blog powered by Plerd. I’ve blogged a bit over on blogs.perl.org but the platform is so frustratingly awful that I gave up. I applaud anyone that regularly uses that platform and still has hair.

I should also mention that I have more or less become just another Perl programmer after having spent the last 20+ years as an IT executive managing a development group consisting of C, Perl and Python developers. I had caught a bit of an itch to return to my technical roots after diving into the cloud and working with my team to migrate 30+ years of legacy code to AWS…soooo…

After leaving my cushy executive job I took a position with a truly wonderful company EPAM as a Senior Delivery Manager responsible for delivering solutions to some pretty big companies. If you don’t know much about EPAM, please take a look. With thousands of employees in Eastern Europe and other parts of the world they have become a global consulting firm that supports all industries and works with all of the big tech companies. Their engineers are first-class. More importantly, their management is superb - open communiciations - real support of employees (not just lip service) and vision. Their support of their Eastern European employees during these troubling times in Ukraine is truly amazing to witness. Leaving EPAM was hard, but after my last project there the technical itch was too strong not to scratch.

Being hired as a Senior Delivery Manager meant I would probably return to projects where I would have more management responsibilites than technical ones. With EPAM’s top-notch engineers in other parts of the world that could be assigned to projects at much lower-costs than on-shore resources it would have been difficult to justify putting me on projects in a technical role. Hence, I found a more technical job - supporting yet another legacy Perl application. After 20+ years of working with Perl I think I might be competent enough to pull it off. That’s not a sarcastic way of bragging…I mean it has truly taken 20 years for me to feel some degree of mastery in the language, but I’m still learning.

In my last stint at EPAM I was asked to take on a slightly different role from Delivery Manager. In my company profile detailing skills and experience I listed my work with Perl which apparently caught the eye of a desperate Delivery Manager in need of a Perl developer. As all Perl developers know, the skill is becoming harder and harder to come by so he reached out and asked if I might be interested. After being interviewed for the role, I was assigned to an amazing team of EPAM engineers to help migrate a legacy Perl application to AWS. This was not an ordinary lift & shift, but rather a reboot of the application using containerization. Containerization of the application allowed us to do several things:

1. Create local development environments that could be easily provisioned by new developers.
2. Use local services like minio or LocalStack for mocking AWS services.
3. Leverage AWS Fargate to create a more scalable application.

Containerizing the application required a first-class build system that could create Docker images containing all dependencies…and that’s where my tale of woe regarding versions first started.

• What version of Perl should be used in the container?
• What are the dependencies of the application? What version of the dependency should be used?

This blog however, is not about that project (I may blog about it later) but rather a blog about my current battle with perl versions, CPAN Tester Reports and CPAN module versions. To conclude part I of this blog, I’ll list some of the issues I’ve been dealing with. In the next chapter I’ll start to detail my experience, frustration and approach to solving them.

• What version of perl should I be using for development?
• If I publish a CPAN module, what version(s) of perl should I support?
• What version of a dependency do I really need in my module?
• What should I do if I receive errors in the CPAN Testers Report?
• Should I include core modules as dependencies? (the answer is not as obvious as you might think)

…more next time