I appreciate the extensive discussion regarding perl version support and PDL. Rather than try an in-thread response, I will try to condense the discussion and extract the key points as I see them along with comments:
* Specific perl versions: 5.10.x, 5.12.x, and 5.14.x Of the three, only the perl 5.10.x version had specific justification for change. The response for the other versions were along the lines of "no reason" or "why not?" * Policies for perl version support included: - Last 5 stable perl versions - Default system perls for some set of OS and platforms - A clear statement was desired. I like the idea of a clear statement of the PDL plan for support of perl versions but would prefer to see PDL policy be based on PDL issues and not on an artificial synchronization with xxx software or hardware update/support schedule. A documented policy for PDL support would help PDL users to coordinate their update requirements. * Philosophy/justification for different support strategies: - To force distributions to update their perl versions - Feature X or Y would be nice to have - Force use of user installed perl via perlbrew or ... - Concessions would be given in special cases only - Can't support ultra-stable distributions (would never upgrade) - If we're not up-to-date, perl doesn't look modern enough Let me start out with my general approach for PDL support: PDL should "just work". That means that folks using PDL to get the job done should be able to rely on PDL working for them over time. The catch is, as the supported version of perl begins to lag the current release versions, it becomes difficult to maintain as the developers are often at the current release version of perl and may or will be unfamiliar with things that have been stable---and often better---in current releases. A mitigating factor is that PDL users using stable installs are almost always using an old release of PDL. Specific to the 5.8 -> 5.10 bump discussion, PDL-2.2 through PDL-2.007 have supported perl 5.8.x and above so these users would be able to take advantage of years of bug fixes and feature improvements as their platforms catch up distribution-wise. * Currently have 20 responses to "show of hands for PDL users" This is what I like to call the "dark matter" problem for PDL development and support decisions (a nod to the astronomer origins of PDL itself :-) . The problem is that the feedback from mailing lists and developers does not reflect the complete set of users of PDL. And I hope there are more than 20! Without such information, our decisions must be made on some assumptions about the PDL users and what they would like and us acting on their behalf. * Options to provide perl+PDL build and installs This was a promising set of discussions involving perlbrew, SciPDL, magical install scripts,... but it could be a way out for PDL users in general. We could aim to provide PDL distributions that include a perl install, not as the only install options, but as a way to assist PDL users with their support and migration issues. With the above in mind, I suggest the following: - PDL development will maintain support/compatibility for the 5 most recent stable versions of perl. - Deprecation and transition to a new minimum perl version shall be as smooth as possible. I.e., we shouldn't jump into a new version of perl by refactoring every possible thing to use features of the new perl. - The PDL distribution will include information about the required version of perl, but we need to also indicate this in each module that actually requires that perl version. The idea being that users needing to implement or support an older perl release might readily tell where things would need to be skipped or back ported. - Provide clear and simple documentation for how to install a local perl and/or PDL distribution to make it easier for PDL users to track more current distributions. - Maybe we could have some sort of minimal install "registration" script that would allow us to track which versions of perl and PDL are being used together. - For the bump to perl 5.10.x, I suggest leaving the core PDL distribution version requirement at 5.8.x but with PDL::IO::Storable not compatible but the tests are skipped if the perl version is < 5.010. The formal bump to requiring perl 5.10.x would occur *after* the remaining issues with 64bit index support and double precision truncation are resolved. That seems a reasonable point to start the new policy. Comments or other feedback welcome! Chris _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
