On dependency version pinning
Two ways of using a module or perl API function:
1. Read documentation. Check changelog, check open bugs. Use only "good" modules.
3. Decide which API of module/perl function to use and how.
3. Write code, write tests. Write assertions in production code. Write proper error handling.
4. Test on several perl versions and several module versions.
5. If tests fail somewhere, investigate, change minimum version requirements or workaround problem.
6. Write down strict minimum dependencies in makefile etc.
1. Briefly read documentation.
2. Write code
3. Test manually.
4. pin module version
5. always use one version of perl, use perlbrew, never upgrade.
So I think Second Way just introduces a technical debt. You save time during development, but the end
you have no idea how your code works and where.
I see lot's of advices to use perlbrew instead of system perl, because system perl can be broken (it can, indeed), articles about Gemfile-lock-like systems.
It looks like those advices mostly for/from people who prefers Second Way.
You don't really need version pinning if you use First way (well, it's useful but you can live without that), it's also not a problem to upgrade perl, if you do so and find a bug, that most likely will be bug in your code. And fixing a bug means reducing technical debt.
Both ways are OK, the Right Way should be determined from business requirements, but I think people
should understand why and when use which approach.