|
Re: Philosophy for when not to support older versions of perl
by Tux (Canon) on Mar 30, 2016 at 06:17 UTC
|
I supported Text::CSV_XS back to 5.005 until the maintenance cost to keep 5.005 alive was outweighing the cost of fixing bugs and/or adding features. (I dropped 5.005 support in June 2012)
Having 5.8.4 as a minimum is a good starting point if you require working Unicode and/or 64bit operations, pointers and ints. Unicode before 5.8.4 is buggy. Really buggy.
Even though Devel::PPPort eases porting for XS over to older versions, supporting 5.6.x really requires extra steps in the XS code for certain operations and or features, and requiring ifdef forests is no fun.
Another reason to have a minimum required version is the minimum version officially supported by the toolchain. At the moment of writing, that version is 5.8.1.
And of course, a good reason to raise the minimum is when a module you depend on, e.g. DBI, raises the minimum to a version higher than your minimum, so supporting a lower version is pointless (if you require that newer version of the module that raised the version).
Enjoy, Have FUN! H.Merijn
| [reply] |
Re: Philosophy for when not to support older versions of perl
by VinsWorldcom (Prior) on Mar 30, 2016 at 01:01 UTC
|
Just as an example, I do a lot of network programming and a few years back went through and added IPv6 support to my modules. IIRC, IPv6 routines (get*info(), inet_ntop/pton()) didn't show up in Socket.pm until around 5.14 and even later for IO::Socket::IP to be included in core. So I have extensive workarounds to "detect" if IPv6 is supported on the version of Perl and then spit a warning / error to upgrade, add Socket6, or whatever the fix would be.
I suppose I could have just bumped the required Perl version in my Makefile.PL, but the IPv4 portion of my modules worked fine and I felt adding IPv6 shouldn't discontinue use of a working IPv4 piece of code on older Perls.
Not sure if that helps or answers your question?
| [reply] |
|
|
That's definitely a great example. I'm an Internet network engineer by trade (my tech trade that is, much of my time has been divested in IPv6 since the early adoption phase), and actively seek out network modules on CPAN looking for fixes that may need had.
This situation is one where it was worth the time spent (imho).
| [reply] |
Re: Philosophy for when not to support older versions of perl
by Corion (Patriarch) on Mar 30, 2016 at 08:33 UTC
|
Looking back, I made my decisions for Perl versions mainly on the basis of availability of features and availability in distributions:
- 5.004_xxx - an ugly version of Perl that didn't have some regex quoting features
- 5.005_003 - the absolute minimum I want to work on
- 5.6.x - introduction of lexical filehandles
- 5.8.x - better Unicode support, distributed with Redhat
- 5.14.x - distributed with Redhat
- 5.16.x - fc operator for Unicode fold-case comparisons
- 5.18.x - signatures
I use function signatures in some pet projects and really like them, but so far I haven't found a good enough reason to make modules for general consumption unusable under 5.18, or enough motivation to release my hacked together Filter::signatures, which implements very simplicistic function signatures under any Perl version. I also dread the support questions of people using source filters.
| [reply]
[d/l] |
|
|
All the 5.8.x versions I ever worked on already had defined-or because of the available patchset. Defined-or is present in almost every script I write.
5.8.x needs to be 5.8.1 or 5.8.4: 5.8.0 is not suitable for production.
Enjoy, Have FUN! H.Merijn
| [reply] |
Re: Philosophy for when not to support older versions of perl
by vkon (Curate) on Mar 30, 2016 at 07:58 UTC
|
this is often about bloating the code, affecting efficiency (AKA speed) and weighting all this.
I am always against pollutions of perl documentation with phrases like "starting with version 5.6 this function does this and that", which is - unfortunately - not a seldom in our perl documentation.
officially perl supports this and previous releases, but in practice this is a bit different | [reply] |
Re: Philosophy for when not to support older versions of perl
by jellisii2 (Hermit) on Apr 08, 2016 at 12:20 UTC
|
I don't write for the general public, but my stick would be something like "whatever RedHat and ActiveState's oldest current LTS supports." My gut on this mirrors what's I'm seeing indicated above; >5.8.0
That said, what are the users of your code saying?
| [reply] |
Re: Philosophy for when not to support older versions of perl
by BrowserUk (Patriarch) on Mar 29, 2016 at 23:31 UTC
|
You wrote 3 lines of text -- which are probably longer than the 3 lines of code required -- to ask this question.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
What I meant was, how much time and effort are people willing to dedicate to research and test code that will work against 10+ year old versions of perl when we may have gotten used to updated idioms.
I know personally I've gone many, many hours to do so. A side question... is the effort even worth it?
| [reply] |
