Chris, this is terrific. I am on board with all your suggestions. After all, it's not hard (and also is good practice) to put "use v5.10" at the top of a module.
On Nov 25, 2013, at 11:59 AM, Chris Marshall <[email protected]> wrote: > 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 > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
