create new tag
, view all tags

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.

  1. I only explicitly test on Indigo Perl 5.8.6 and Debian Etch Perl 5.8.8
  2. 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:

  1. Add your earlier perl installation as a required test step in the release process,
  2. Obtain/provide a server where tests can be run automatically.
  3. 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

Perl Version Tester Versions tested
5.8.6 CrawfordCurrie 3, 4.0.1, 4.0.2
5.8.8 CrawfordCurrie 3, 4.0.1, 4.0.2
5.6.5 EricWoods 4.0.5
5.6.5 EricWoods 4.1.0 FAILED
5.6.1 KennethLavrsen 4.1.2

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.


-- 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:


  • 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 wink (I'm kidding) wink )
  • 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.


  • 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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

Edit | Attach | Watch | Print version | History: r31 < r30 < r29 < r28 < r27 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r31 - 2007-04-25 - KennethLavrsen
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.