in reply to Determining minimum Perl version for new module
I see backwards compatibility as a major pillar of the Perl community, so I would suggest aiming to support whatever version provides the features your API needs, within reason. For example, I am currently working on a WARC library for Perl and the API uses tied lexical filehandles — and there were bugs in 5.8.0 that resulted in leaking lexical filehandles, so 5.8.1 is the minimum for my project, even though some versions of 5.6 might be able to run my code.
That said, there is still at least one 5.8.5 smoker out there, (and my non-broken tests have passed on it) so as a practical matter I would be more inclined to bump the required version rather than work around bugs in perl releases even more ancient than that.
My philosophy is generally to let older versions run the tests and see if I get failure reports, but to go ahead and exclude versions known to have bugs that would cause disaster if the code were put into production. I am up to "alpha-5" as I call v0.0.0_5 currently. I follow release early, release often, as long as the tests exist and pass: the very first "alpha-1" release had no actual code, just empty subs and stub unit tests to ensure that the modules parse OK and verify the embedded POD. Each subsequent release has been a step along the way to building the library, while rolling in bug fixes for previously-failing tests.
The CPAN smokers seem to all run various Unix-like systems but are still an impressive variety of configurations. If your distribution has a version with an underscore instead of a dot ahead of the last number, the smokers will test it but it will only be installed for users if specifically requested.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Determining minimum Perl version for new module
by hippo (Archbishop) on Sep 13, 2019 at 08:57 UTC |