模块:我何时应该在文档中提到所需的Perl版本?

时间:2012-10-22 12:09:34

标签: perl documentation version

哪一个是最高的Perl版本,我不再提及作为文档中的要求? 例如,我从未见过:需要Perl 4或更高版本。

4 个答案:

答案 0 :(得分:7)

最终,向用户提供额外信息没有任何害处,因此如果您知道即使是非常旧的版本也不兼容,您也可以提及它。

然而,Perl 4被认为是一种单独的语言。没有必要提到这一点;没人会指望C ++程序在C中运行。

从这个论坛的人们的问题来看,5.8仍在广泛使用。因此,如果您有兴趣制作一个经过充分测试并且尽可能广泛使用的模块,我认为至少可以通过测试来回溯那么远。

如果您需要运行某个版本,则在您的模块中使用require VERSION可能有助于强制执行此要求。这样,如果用户尝试在太旧的版本上运行模块,则会收到明确的错误消息。

答案 1 :(得分:4)

记录您实际测试的最旧的Perl,无论可能是什么。别猜它;不兼容性蔓延。如其他人所述,请在代码中使用use v5.x和模块元数据声明最低版本。

你应该走多远?无论您愿意支持和测试最旧的版本。这是你的时间和潜在的挫折感。你越往后走,你错过的功能越多,CPAN模块的工作越少,你需要解决的bug就越多。

如果您正在使用线程或Unicode,请尽可能使用最新版本。 Unicode支持总是在不断改进。线程在5.8开始时非常错误,在5.10开始变硬并且从那以后变得更好。

5.10.1是一个非常安全的最低限度,你会得到像autodie, parent, compression and archive modules, defined-or, say, given/when, smart match and named captures这样的东西。 5.10.1特别是因为it fixes how smart match works in ways incompatible with 5.10.0。它是what comes with Debian stable,这是兼容性较低的标准。这是大多数CPAN模块最早可以获得的可靠支持。

之前的下一步是5.8.9,5.8系列中的最后一步。这是最古老的Perl,你可能会在一个理智的生产环境中看到它。你失去了很多功能,线程不太可能工作得很好,Unicode仍然有点不稳定,CPAN模块开始崩溃。

在此之前是5.8.4,这是已知的最早的Perl,它带有主流操作系统,Solaris。这是一个handy list of operating system versions and what Perl they shipped with

之前是5.6.1。 5.6.2虽然包含许多错误修复,但从未被广泛采用。在这一点上,你有几层深层的硬壳,尘土飞扬的安装,永远不会升级。存在线程和Unicode支持,但形式非常不同且非常破碎。许多CPAN模块不支持5.6。

5.005_03和5.004_04是下一个摇摇欲坠的壁架。此时成为受虐狂或学术活动。您可能会发现一些非常古老的安装,或者一些“Perl在添加线程和Unicode之前更好”。

5.004之前的任何内容以及foreach my $foo等非常常见的语法都不可用。

答案 2 :(得分:3)

www.perl.org:

  

当前版本:Perl 5.16.1

所以也许5.10之上的任何东西都可以提及。

我使用Modern :: Perl

  

概要

     

Modern Perl程序使用多个模块来启用Perl和CPAN的其他功能。而不是复制和粘贴所有这些使用行,而是只写一个:

use Modern::Perl
  

为了向前兼容,我建议您指定一年作为单个可选导入标记。例如:   使用Modern :: Perl'2009';   使用Modern :: Perl'2010';

     

...都启用了5.10功能,......

另见: perldoc Modern :: Perl或https://metacpan.org/module/Modern::Perl

答案 3 :(得分:2)

如果您知道需要最低版本,为什么不记录它?依赖关系通常记录在README文件中,并在Makefile.PL或Build.PL中指定给安装程序。

5.14和5.16是Perl唯一支持的两个版本,但许多仍然使用5.8和5.10。我偶尔会听到5.5和5.6。