What versions of Perl does TWiki support?
A
recent bug highlights once again the ambiguity of what versions of perl TWiki supports. It is
totally unacceptable to claim support for platforms that are not tested.
So, what platforms are tested? I can only speak for myself.
- I only explicitly test on Indigo Perl 5.8.6 and Debian Etch Perl 5.8.8
- Before the server move, ~develop ran on 5.6, so we could reasonably claim to support that as well. ~develop and ~twiki now run on 5.8.5
So I am only happy claiming support for these two platforms. I do not consider TWiki's support claims (in
TWikiSystemRequirements) to be valid, as I do not test on any other platform than 5.8, and
no-one else claims to test on any platform other that 5.8. I therefore propose (again) changing the support requirements to perl 5.8, with a note to the effect that it will probably work on 5.6 but is untested. Further, the perl module versions in
TWikiSystemRequirements have not been kept up to date and are equally untested.
If you are particularly concerned to advertise support for earlier versions of perl, then I would suggest the following options:
- Add your earlier perl installation as a required test step in the release process,
- Obtain/provide a server where tests can be run automatically.
- Keep the following table up-to-date, and scrap the "TWikiSystemRequirements" except as a link to here. NOTE: "TWikiSystemRequirements" is actually an old, read-only page for version 4.0.2 - Instead I reccommend TWikiSystemRequirements where I have updated the Perl req's - Main.EricWoods
There is also an issue with the versions of
CPAN modules that are tested.
CGI recently had problems with a couple of releases that make some
CGI versions unuseable.
I18N requirements also add extra constraints to both the Perl version and the
CPAN modules versions.
And that's before we even get started on plugins.
--
CrawfordCurrie - 04 Jun 2006
Some other questions about bugs that occur only with ancient versions of Perl:
- Who will have access to the ancient Perl machine? Only those people will be able to fix bugs that occur.
- What happens if a fix winds up creating new bugs for more modern versions of Perl?
- Do we want to spend precious resources fixing those bugs, when there are plenty of regular ones in Bugs already
--
MeredithLesly - 04 Jun 2006
And who is running older than 5.6 versions?
--
RafaelAlvarez - 05 Jun 2006
Probably the same people who are running Beijing.
--
MeredithLesly - 05 Jun 2006
This issue has just been opened up again since 4.1 was released, as I added (in Jun 2006) a require on Perl 5.8 in
configure
, after I received reports that it did not work in earlier Perl versions. The require has been in the code since r10475 (TWiki4.0.3?).
Please don't be shy about expressing your opinions here; if the TWiki project really needs to support earlier Perl versions, then we need to know about it.
--
CrawfordCurrie - 24 Jan 2007
TWiki 4.0.5 has this in
configure
:
$perlverRequired = 5.00503; # Oldest supported version of Perl
TWiki 4.1 has this in
configure
:
eval 'require 5.008';
TWikiSystemRequirements documents this:
Perl 5.005_03 or higher (5.8.4 or higher is recommended)
The
configure
script in TWiki 4.1 has now a hard coded requirement on Perl 5.8. This was fixed and restored to the documented 5.5.3 as tracked in
Bugs:Item3476, but later pushed back up to 5.8. There is no need to engage in a ping-pong scenario, let's follow our documented process.
We need to resolve four issues: Customer focus; not raise TWiki system requirements arbitrarily; make community based decisions; do what we say.
1. Customer focus:
Some developers expect all users downloading TWiki to know about Perl,
CPAN and system administration. The reality is that only a small percentage does. If we expect all users to know as much as the dev team we will lose 90% of the evaluators because they get stuck at some point of the installation and give up. I have seen that more often than I like to see. We need to try hard to make it easier for Joe Goodwill to download and install TWiki.
2. Not raise TWiki system requirements arbitrarily:
The system requirement of Perl is documented as 5.005_03 (aka 5.5.3); TWiki 4.0.x had a hard requirement on Perl 5.5.3; TWiki 4.1 has suddenly a hard requirement on Perl 5.8. This change slipped into the configure script without anybody noticing it. I consider this change a bug, and it is fixed for the upcoming 4.1.1.
3. Make community based decisions:
We have a solid process that helps enhance TWiki so that it is in line with the majority of the
TWikiCommunity and with the
TWikiMission. Changes to TWiki that have an impact on the users need to follow the process we defined at
TWikiRelease04x01Process. Raising the hard requirement on Perl from 5.5.3 to 5.8 certainly falls under that category. If we raise the required environment for TWiki it should be done in line with our process.
4. Do what we say:
We claim that TWiki runs on Perl 5.5.3, but nobody is testing, and nobody is reviewing the code if it actually runs on that version. We made a lot of headway in automated testing thanks to Crawford and other folks. To me it looks like this infrastructure is a good opportunity to test TWiki on Perl 5.5.3.
So, let's do the right thing: Follow the process the community agreed on, debate what Perl version we should support, make a decision, document it, and take action. Please base this on the current documented state,
TWiki requires 5.5.3.
--
PeterThoeny - 24 Jan 2007
I added this to
TWikiFeature04x02 tracker topic to start the process:
This starts the debate. My recommendation is:
- Keep Perl 5.5.3 in TWiki 4.1
- Raise to Perl 5.6.x in TWiki 4.2 (the first stable .x)
- Do automated tests that support that (nice to have)
--
PeterThoeny - 24 Jan 2007
I don't know if I can be classified as a 'developer'. I rarely contribute code and the testing I do is driven by "operations" not by
TWikiMission. My vision differs too greatly from Peters. I suspect that if I had the time to code I'd fork, and do many of the things Crawford and others dream of; but since I don't I use what is available - a version of SWAT, I suppose.
However I consider the lack of a sunset to be a bad and limiting strategy. You have to let go of the past to deal with the future.
More and more people are using Linux, and they don't seem to be using archaic versions of Perl. Who
is using archaic versionas of Perl - except where mandated by archaic versions of TWiki?
I'd also not that most upgrade tools have a dependency mechanism built in. However the real problem with upgrading TWiki is two fold.
First, the upgrade is an overwrite. This has been discussed, and despite what Peter says its a major impedement. If you think about it, its counter to the
TWikiMission.
The other impediment, the other reason to run archaic software, but in this case of TWiki rather than Perl, is that later relases of TWiki are slow. Slow as in unresponsive. I could lecture all day on why developers perfer features and functionality to speed, but we all know that song by heart. If TWiki were scalable "out" this could be aleviated, but it isn't.
The issue isn't what version of Perl Twiki requires. That's a bottom-up view of things, obsession with the details and missing the big picture. I'm seeing so much of that and its one reason I haven't been participating much. Being invovled in such nit-picking isn't conducive to a good enviroment.
I'd suggest a good roadmap that defines sunset for various things. And I'd start with a sunset on using a flat file store. TWiki is the last decent Wiki/CMS to be stuck with that.
Focus on real issues, Peter, not this petty stuff!
--
AntonAylward - 24 Jan 2007
Not everyone is watching closely what is happening on TWiki.org. Actually, overall we do have a community that interacts in a professional manner, thanks to the folks who helped define and refine our
release process. Doing the right thing for the TWiki project, in line with the
TWikiMission and the
TWikiCommunity, feels like a sunrise to me. Finger pointing is one thing, getting involved actively and in line with our release process is onther thing.
I am not aware of any active developer who is holding back progress, such as helping improve the performance, creating a DB backend with compatibility in mind, making upgrades dead simple, or strengthening TWiki as an application platform. Just look at the
FreetownRelease and
TWikiFeature04x02.
Back to the subject, I am looking forward to see some more data on the environments and skill sets of our users so that we can make an informed and customer focused decision.
--
PeterThoeny - 24 Jan 2007
We should have a sunset, but Perl versions are a real issue for some. People running TWiki on webhosts have little option but to use an older Perl - e.g. the very popular 1&1 host is
http://twiki.org/cgi-bin/view/Codev/TWikiOnWebHostingSites#1and1 still on Perl 5.6. The same applies somewhat to intranet servers running old operating system versions - I suspect there are quite a lot of those.
Since 5.5.3 is very old now, I would say we drop support for it soon, if not immediately, and just focus on 5.6 and 5.8, recommending 5.8 as now.
--
RichardDonkin - 24 Jan 2007
The issue of Perl version is not grabbed out of nowhere.
It comes from a number of our old loyal customers that used TWiki 4.0 on Perl 5.5.X and now cannot upgrade. The customer in question works for a company that buys a hosting product from some supplier running an old Linux. I chatted with him yesterday and suggested to find another provider that is not so out of date. But this provider is the main provider for this corporation and the TWiki is a very minor part of the equation. The customer in question is now stuck on 5.5.3.
When you paint a picture of a sunset, it is in reality the community giving these customers "the finger". The "petty stuff" is a matter of caring about others than yourself. To the customers not being able to upgrade is a real issue. Naturally we cannot continue supporting very old versions and there may be features that simply cannot work unless you have certain
CPAN libraries. But think forward. If an organisation is not thinking about existing customers NOW they will not think about YOU in future - and you should stay away. When you read the
TWikiMission it is all about caring for our customers. The existing old ones, and the new ones.
The basic TWiki has not really changed that much and TWiki 4.1 is mainly round 200 bug fixes and 50 small enhancements. There is no technical reason why it cannot run on Perl 5.5.3 with at least the more features.
And if it is only the configure script that sets the requirement then it is a dammed pity. And if on top of it it is just one code line that blocks the running of the configure tool and it actually could have run, it is even a bigger pity.
The problem with promising 5.5.3 support is that no developers have a machine with this version. And Crawford is right that if we want to claim Perl 5.3 and Perl 5.6 we need test facilities to run it. We cannot just claim it works if we do not test it.
So let us find a solution for this instead of throwing mud at named people.
- How old a Linux distribution would we need to get perl 5.5.3?
- Is it possible to have two Perl versions installed and control which one you use from the shebang line and environment variables?
- Could we perhaps create a VM with an old distro which developers can use for testing?
- Maybe I could run such a VM with an apache on an other port than 80 on my merlin.lavrsen.dk testbed?
- Has any other OSS project based on Perl solved this?
--
KennethLavrsen - 24 Jan 2007
Well put, Kenneth!
--
PeterThoeny - 24 Jan 2007
RedHat 6.2 seems to be the last RH with Perl 5.5.3. I will try and see if I can make a VM with that.
--
KennethLavrsen - 25 Jan 2007
You can have diferent versions of perl runing alongside each other. The way I have it set up, I have Perl 5.6.x in the default directory (the control panel for Mandrake Linux requires it...) and 5.8 installed in /usr/local/perl58. To do that, I rebuilt it from the sources specifying the default directory.
m2c
--
RafaelAlvarez - 25 Jan 2007
This is a big idea dump, so feel free to refactor to the proper place.
Regarding supporting users with old infrastructures: Trying to remain compatible with each an every previous version of a programming language has the efect to drag down the development of the product, eventually stagnating it, as there is not possible to use the new features (new syntax, new core libraries,new supporting libraries, etc).
So, let's do a sanity check. First, let's suppose that tomorrow we decide to stop adding
new features to the TWiki version that supports 5.5.3 (but continuing with bugfix releases). What option does the customer have? A quick check on the Wiki Matrix gives the answer: None. Zero. Zip. No other Wiki claims to work on Perl older than 5.6.
It's a shame, but people running RPG on mainframes cannot expect to have an
WYSIWYG GUI.
Now, let's see the kinds of installation TWiki can have:
- Shared Hosted installation: The user do not control what is installed in the system. Upping the requirements is a "no-no" for them. And some (if not most) of them don't know that the heck CPAN is . For them we need TWiki to be "unpack and go". But there are a LOT of other wikies that are easier to install than TWiki in this kind of enviroment.
- Dedicated or Virtualized hosting: The user has complete control over the enviroment. Most of them have a solid background of admin skills. For them, is just a small hassle to need to run an installer that downloads the CPAN modules needed and installs them before TWiki can run. Upping the requirements for them is not a big issue.
- Coporate Installation (non-regulated): These are maintained by admins. Same case as above.
- Corporate Installation (regulated): What Kenneth described.
- Personal Wiki: Same as dedicated or virtual hosting.
In all these spaces, nearly every Wiki (except perhaps
TidyWiki, and some wikis that bundle the http server) requires at least some admin skills. And for most wikis, you need to be confortable using a database.
So, as I have stated somewhere else, before focusing on the "customer" we first need to identify WHO the customer is, because the real fact is that TWiki has many kind of customers, and perhaps we're focusing too much on one kind and losing the marked in the others (people that go with any other perl based wiki don't have Perl 5.5.3 installed on their machines, for sure).
Do you want TWiki to be a success? Make it
installable, and that means clear, complete, concise, step-by-step, accurate and current documentation on "How to install the d@$% thing". I asure you, there is none. There are a lot of pages about installing TWiki, but with them a 30 minutes process (counting download time with DSL of TWiki and all libraries) may last 3 or 4 hours the first time.
And please, don't say "you're welcome to write it", as I'll not do it. First of all, I'm a very bad documenter (as Crawford discovered the hard way long time ago). Second and last, I'm not the one bitching that we're losing "customer focus". People shoud be doing things that matter, instead of bitching about other people's work.
Now back to hibernation.
--
RafaelAlvarez - 25 Jan 2007
Saying that a sunset on a certain level of support or certain products is giving the customer "the finger" is either an indictment of our whole industrial base - not just IT - or admitting that we have some funny ideas about how we allocate resources.
I see the developers interested in the next release, in features. I know from having been a developer, project manager and owner of a s/w development company that many things such as a good installation mechanism, a good upgrade mechanism and of course that great demon of documentation are less interesting. But they are necessary.
Much of the software I use under Linux and AIX and Solaris and I'm told the same applies to other 'professional' operating systems such as Windows and MAC OSX addresses these. I can update using RPM that checks for dependencies and make sure that other needed packages and components are installed. The same applies with the wikis and cms and other tools I use built with Ruby. (On that, you might look to how Ruby-On-Rails applications update non-code content and how the compartmentalise custom code.)
Making a package that is
installable or
upgradable doesn't
have to mean detailed instructions, certainly not for the end user or the site administrator. In fact many such people don't have the time or inclination - the classic case of
"Don't Make Me Think". The VM-TWiki is a good example.
Other matters like those expressed in
StopShippingTWikiUsers are an impediment to upgrades. The "overwrite everything" approach to an upgrade is
NOT acceptable. As such it is a strong disincentive to upgrade. Once bitten, an end user (aka administrator aka installer) is going to feel the need to do a recursive DIFF to make sure he doesn't get bitten again. And that still won't help with many issues like changes to the menu bars. As Raphael says, what could be a minor and possibly automated process (as updates are for my Linux system and work AIX systems) turns into many hours work requiring close attention.
If Microsoft and hundreds of other companies can deal with non-destructive upgrades why can't we?
"If someone is going down the wrong road, he doesn't need
motivation to speed him up. What he needs is education to
turn him around."
Process improvement, corrective strategy,
auditing - which is my profession - is not "bitching about other people's work".
--
AntonAylward - 25 Jan 2007
Back to the original issue. The issue is which version of Perl should TWiki support.
If it takes a few code lines to make TWiki 4.1 work with 5.5.3. If it takes two staff months then it is not going to happen.
So my target is to get a test bed up so people can test with 5.5.3 so we can assess the size of the job. And then we can decide from there.
The proposal from Peter to say that if TWiki 4.1 can run on 5.5.3 then we make a few more customers happy but we will declare that this is the last release where 5.5.3 will be attempted supported. But we then still have to create a 5.6.X test environment for the future.
I have downloaded a RedHat 6.2 and will try and see of I can get a VM to installed with it. I am not sure it is possible. I will give it a try.
I am not sure it is very easy to install and maintain an old Perl version. The perl itself maybe but post-installing the needed
CPAN libs will not be trivial. At least not for me. So for now trying to create a VM is the first thing I will try. I will return when I have some experience with this. We need to address the 4.1.1 urgent bugs first.
--
KennethLavrsen - 25 Jan 2007
To get Perl 5.5.3 working, it might be easier to build Perl from source on a modern distribution, enabling the 5.5.3 tests to be run alongside tests on 5.6 and 5.8. I did a Perl build of 5.8 when my web host only supported 5.6 and it was really quite straightforward.
http://www.cpan.org/src/5.0/ has the older Perl versions in source form - will just try this on Ubuntu Breezy 5.10 (released in Oct 05). UPDATE: Just tried this and it doesn't work without hacking, so a Red Hat 6.2 VM sounds simpler.
--
RichardDonkin - 27 Jan 2007
Anton, sorry if you took it personally. By "bitching about other's people work" I mean spending more than year trying to block the discussion about something you don't want to change, even if there are reasons to change it, without giving a good "alternative" or "compromise". I don't think Kenneth or you are bithching. Yelling out loud about things that you don't like, yes. Providing reasons for your yelling, yes. Bitching, definetively no.
About TWiki being installable, I sometimes get mixed signals here. Since Beijing (the first version of TWiki that I installed), the assumptions is that the one installing it has at least minimun knowledge about the webserver and OS administration skills. But sometimes we said that people that are installing twiki are
to dumb to learn to use
CPAN or to follow the instructions to install the required libraries from a mini-cpan mirror.
Having one or several (one per case) install scripts that do the magic would be wonderful, but is good anyway to have the instructions to install TWiki on every case, or else the installation process will become "black magic" and could not be tweaked easily for those case that the install script don't work.
One of the best installation guides I have seen is the one from subversion. It does assume that you know your stuff, but anyway guides you through the process from compiling apache from the sources, to compile subversion linking to the right APR version, to configure apache to see your repository.
Time consuming to write, but I think it's worth the effort.
--
RafaelAlvarez - 27 Jan 2007
Interesting discussion.
I run slackware linux on my machines, which is generally tolerant about switching between different versions of installed software. So I took a crack at installing perl 5.5.3 this evening and running TWiki 4.0.5. Here are the results:
process:
- looked on distrowatch to find the most recent slackware that includes 5.5.3. Turns out its 7.0. (This is about when I started using linux and I still have a slackware 7 machine in storage. I wonder how slow twiki would be on a x386 with 12MB of RAM (I'm kidding) )
- downloaded the 7.0 tar-ball for perl 5.5.3
- to ensure no collisions between 5.5.3 and my current version, I repacked the tar-ball before installation:
- removed all executables from
/usr/bin
except perl5.00503
;
- deleted
man/man1
directory; deleted install/
directory.
- used
makepkg
to create a perl-5.5.3 package compatible with slackware 10.2.
- installed the new tar-ball.
After perl-5.5.3 was installed, I moved the old symlink to perl and created a new link to perl-5.5.3. (
mv /usr/bin/perl /usr/bin/perl-5.8
.
ln -s /usr/bin/perl5.00503 /usr/bin/perl
)
A few of my other scripts appeared to work OK, so I then tried to run twiki.
outcome
-
bin/configure
won't run. complained that warnings.pm
is not installed.
-
bin/view
won't run. multiple problems here:
- First complaint was at L277 in
TWiki.pm
. It appears perl-5.5.3 doesn't like the qw( ... )
syntax. Replacing the array with an explicit array of strings appeared to resolve this.
- Second complaint was at L165 in
Client.pm
. "Too many arguments for open".
This is as far as I got. The short answer appears to be that TWiki 4.x can't run on perl 5.5.3 without a number of significant changes.
This same process could be repeated for perl 5.6.
Hope this helps.
--
ScottHoge - 28 Jan 2007
Thanks Scott, this is good data to decide what we are going to do.
--
PeterThoeny - 28 Jan 2007
The original reporter that started the latest reporter claimed that he had run TWiki 4.0 on 5.5.3. If Perl 5.5.3 cannot understand qw() syntax then this cannot be true because 4.0 was full of these.
If we have to do that dramatic changes then it would mean goodbye 5.5.3.
--
KennethLavrsen - 28 Jan 2007
after a bit of sleep, it occurred to me that the
qw( ... )
syntax has been around since at least perl 4. And sure enough, it works from the command line, e.g.
perl-5.3 -e 'print map {"\t$_\n"} qw( a b c )'
works just fine. What doesn't work is
foreach my $ltr qw( a b c ) { }
. Wrapping the
qw
within an array
does seem to work however,
( qw( a b c ) )
.
I'll see today if I can get TWiki running on perl 5.5.3 with minimal changes.
--
ScottHoge - 28 Jan 2007
Ahhh, fun, fun, fun.
L607: TWiki.pm: 'use bytes;'
from ExtUtils::MakeMaker::bytes
"bytes.pm was introduced with 5.6. This means any code which has 'use bytes' in it won't even compile on 5.5.X. Since bytes is a lexical pragma and must be used at compile time we can't simply wrap it in a BEGIN { eval 'use bytes' } block."
--
ScottHoge - 28 Jan 2007
Well, limited success, within about 20 minutes.
- I used an
eval "use bytes;"
, and the problem with bytes
was bypassed.
- Needed to install File::Temp from CPAN (latest version, but hacked to bypass req on File::Spec version >= 0.8)
- need to modify to following files, changing
open
to 2 args and embedding qw( .. )
within an array. (and one change to mkdir
)
- ./lib/TWiki.pm
- ./lib/TWiki/Client.pm
- ./lib/TWiki/Store.pm
- ./lib/TWiki/Store/RcsFile.pm
With these changes, I could view twiki pages. SEARCH doesn't work yet, however. Attached is the diff output. Pretty limited changes.
--
ScottHoge - 28 Jan 2007
Thanks Scott for making headway in 5.5.3 support!
--
PeterThoeny - 28 Jan 2007
Thanks Rafael for pointing out the different types of admins, this helps in making a decision. However, I get quite a different picture based on the
TWikiInstallation directory, my extensive support work in the
Support web, my e-mail correspondence, my consulting work, and the
#twiki
IRC traffic. In order of occurance:
- Behind firewall installation (grass roots): Typically a team lead/member in Engineering, marketing, tech pubs. Person usually has some technical knowledge, but has no experience in web server administration, has no Perl experience, never heard of CPAN. Main concern is to get TWiki installed quickly with point and click and/or with with guidance. In some cases a geek who knows or wants to learn Apache config, Perl and CPAN.
- Dedicated or virtualized hosting: Typically SMBs with limited staff. Typically a technical person with many hats on, is in charge of phone & internet connectivity, office equipment, air conditioning, etc. Has some sys admin experience, but does not know Perl, never heard of CPAN, and is scared to touch Apache config files.
- Behind firewall installation (managed): Typically system admin of IT or Engineering services group; knows about Apache, Perl, CPAN. Is not interested in learning the TWiki app logic; the main concern is backup, ease of upgrade and system monitoring.
- Shared hosted installation: Two camps of users, (1) technically savvy person/geek of an interest group, such as a rocketry club; (2) somewhat technical person of interest group, such as bibel group; does not know Apache config, Perl, CPAN. Both share the same system constraints: The user do not control what is installed in the system. Upping the requirements is a "no-no" for them.
- Personal wiki: Two camps of users, (1) geeks who want to experiement; (2) somewhat technical person who wants to get a wiki as a PIM (personal information manager).
I hope this helps in shedding light on the types of actual cutomers so that we can make an informed decision.
--
PeterThoeny - 28 Jan 2007
Peter, that is a really good summary of user types. Maybe some of the help could somehow cater to these different user types too?
Why I am mentioning this is that I spent probably a whole day trying to install TWiki on the 1and1 host, but had many problems and pretty much gave up before I found the documentation about exactly how to install on 1and1, which was a godsend! In my situation, I had no idea someone would have created such a specialised doc, so I didn't even search for that.
In my case, in the first install instructions I had seen (the install.html in the twiki zip) it would have been great if it linked to specialised install help, mentioning that installing on web hosts was documented there. I noticed that the online version of
http://twiki.org/cgi-bin/view/TWiki/TWikiInstallationGuide does this, but unfortunately the version in the zip does not.
I hope something good can come from my day of pain.
--
EricWoods - 29 Jan 2007
Good point, I created
Bugs:Item3534 to track that.
--
PeterThoeny - 30 Jan 2007
BTW the code that goes as follows is only useful once we have
UnicodeSupport, so I believe the
use bytes
can be omitted completely for all Perl versions:
my $len = do { use bytes; length( $text ); };
--
RichardDonkin - 30 Jan 2007
In my opinion it would be fine to state what version of Perl we have tested the system with. However, we should not hard code this limit as it may in fact work on earlier versions.
--
ThomasWeigert - 09 Feb 2007
Another reason to support Perl 5.6 is that some people on shared hosts can't upgrade to TWiki 4.1 - see comment from
EricWoods on
SecurityAlert-CVE-2007-0669. Anything that makes it harder for existing TWiki users to upgrade can't be a good thing.
--
RichardDonkin - 11 Feb 2007
I have completed testing the combination Apache 1.3.23, RedHat 7.3, Perl 5.6.1. And after very few fixes to the core code, some fixes to the configure suite and some fixes to the unit tests I feel confident to say that 4.1.2 when released will work well on Linuxes with Perl 5.6.1.
I have not tested Perl 5.6.1 on Windows and do not plan to. I would say that most that try to run TWiki on Windows have the possibility to install whatever Perl version they want and so I have personally decided not to waste limited test hours on this combination.
--
KennethLavrsen - 25 Feb 2007
Great news that Perl 5.6 is supported again - shared hosting users will be happy about this, or perhaps simply not find another Wiki that 'works on my hosting service'.
--
RichardDonkin - 26 Feb 2007