In light of the generous offers of continuing support, I can get on board with
this plan.
Thanks,
Judd
____________________________
Judd Taylor
Software Engineer
Orbital Systems, Ltd.
3807 Carbon Rd.
Irving, TX 75038-3415
(972) 915-3669 x127
________________________________________
From: Chris Marshall [[email protected]]
Sent: Monday, November 25, 2013 12:59 PM
To: [email protected]
Subject: Re: [Perldl] [Pdl-porters] update PDL perl version to 5.10.x
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
