Mantis: Dropping Support for PHP 4

We have been thinking about the right time to drop support for PHP 4.x.x for a while now. The main drive is that in order for Mantis to use new PHP 5 features, we will have to drop PHP 4 support. We are thinking that it makes sense for 1.1.x to be the last Mantis release that supports PHP 4.x.x and starting with Mantis 1.2.0 have PHP 5 as the minimum requirement.

Following are some reasons why we think such move makes sense:

  1. PHP 5 was released over 3 years ago.
  2. php.net announced end-of-life for PHP 4 to be end of 2007. Following is a copy of the announcement:”[13-Jul-2007] Today it is exactly three years ago since PHP 5 has been released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable & production-ready and as PHP 6 is on the way, PHP 4 will be discontinued. The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5.
  3. There are a lot of projects who have already upgraded their minimum requirement from PHP 4 to PHP 5, others have joined the gophp5 initiative to move to PHP 5 by February 2008. We are considering joining this initiative.
  4. The time frame for releasing Mantis 1.2.x will be in 2008 and after the gophp5 initiative planned date (February 5, 2008). We are considering having 5.2.x as the minimum requirement which is inline with the gophp5 initiative.

We would like to get feedback from the Mantis users community relating to this change of minimum requirements. It is useful to hear feedback from users in the following categories:

  • Users who are OK with the change.
  • Users who are in favor of the change.
  • Users who are against the change.

Note that Mantis already supports PHP 5, the main change here is to start using PHP 5 specific features like better object oriented features, exception handling, and many others.

54 thoughts on “Mantis: Dropping Support for PHP 4”

  1. ya, keeping php4 support shouldn’t hinder further development. It means that we have to upgrade our servers then, but that is a task we have to do anyways within next 2 months… so absolutely no problem

  2. Drop Php 4. Most web hosters worth hosting with are already in the throes of dropping PHP4. PHP5 is a proven thing – it’s well out of beta.

    The nay-sayers can always stick with the legacy version … and Windows 98 … and coal.

  3. Well, our server is only visible on the intranet, and so we don’t see reasons to update any system software… if all applications work smoothly. That’s simply a matter of administration and costs.

    Now, when you drop the php4 support, we are forced to update. If we had to review Mantis, this would be a “minus”…

    Anyway, since we are using it already, we will follow the crowd.

  4. I agree, you should not continue to long on an old basis. However some ISP’s still use php4 as a basis where you can only switch to php5 by changing the extention of the file to php5. Is there a possibility that there is an extra release with this extention?

  5. It’s about time we all left PHP4 behind.

    PHP5 is such a significant improvement for any serious application development. I’ve been running PHP5 on all my various production servers for a couple of years and not had any issues with it at all.

    It’s stable, fast, works, well under load and above all gives you the functionality you need to write proper OO applications.

    I also can’t see any reason why 5.2 shouldn’t be the minimum requirement – there were actually a few teething problems with the 5.0 and 5.1 branches and 5.2 did cause various backwards compatibility issues, so to avoid those it would definitely be advisable to go for the 5.2 branch as the minimum requirement.

    Finally, I believe that Mantis is exactly the kind of application that would significantly benefit from the removal of PHP4 compatibility restrictions.

    So this proposal has the total thumbs up from me.

  6. I’m a new manits user, waiting for the new version to come out before shifting our corporate “prototype” in to production.

    So for me, dropping PHP4 is a complete non-issue

  7. Hi,

    Dropping PHP 4 support is fine for us.

    But you may want to consider to set PHP 5.1.x as the minimum requirement for the future Mantis versions, since many enterprise Linux distributions ship with it (e.g. RHEL5 ships with PHP 5.1.6) and most providers stick to the PHP version shipped with the OS to get the regular security fixes from the vendor (at least that’s what we do).

    CentOS 5, a very popular and free distribution, is also based on RHEL5 and ships with PHP 5.1.6.

    Regards.

    Marco Di Folco

  8. No problem. Everyone who keeps his servers up to date, has probably migrated to PHP5 already. And everyone who doesn’t, should feel ashamed 😉

  9. I won’t have any kind of problem with this move, because I already use Mantis and TestLink on PHP 5.2.1.
    It’s like the dinosaurs, it’s the evolution…

  10. Announced on ICD soft – they host 85,000 sites …

    System updates; General;
    July 26th, 2007 | IMPORTANT: PHP4 End-Of-Life announced.
    The development team of PHP announced the End-Of-Life of PHP 4. There will be no more releases of PHP 4.4 after Dec 31, 2007. Critical security fixes will still be released on a case-by-case basis until August 08, 2008.

    ICDSoft will continue supporting PHP 4 until possible, but we urge our customers to look for ways to make their PHP applications suitable to run on PHP 5. After the end of 2007, we may be forced to discontinue any support for PHP 4, in case of a discovered security vulnerability which may endanger the integrity of our hosting environment.

    After Sep 10, 2007, we will start setting PHP5 as default PHP interpreter on our servers. This means that files ending with .php will be parsed by PHP5 by default. However, customers will still be able to set PHP4 as default interpreter, by using a directive in their .htaccess files.
    The change will happen gradually on each of our servers and the exact date for each server will be announced later.

    We advise our customers to take the necessary steps to make their PHP driven software completely suitable to run on PHP5. If the software is a third-party application, upgrading to the latest stable version should be enough, as developers of popular software (forums, blogs, CMSs) have already released versions, ready to run on PHP5.

    Any questions about the migration to PHP5 can be directed to our support staff at http://www.suresupport.com/.

  11. Victor,
    It will need to get done sooner or later. We are already into the “later” period.
    It is time.
    Thanks for all your hard work.
    Regards,
    Gabriel

  12. Our web server has v5.2.4 installed so it should not be a problem for us. Thanks for asking.

  13. Our company is typically the last to upgrade this kind of thing. I think we used MySQL 3.2.23 until people started laughing at us.

    Even we have mostly transitioned to PHP5 (because of PHP’s EOL announcement).

    So, yeah, it’s time.

  14. Go for PHP5, I am still fighting with my sysadmin because it uses Debian and thinks that “aged” software is better like wine… 😉 But because Mantis it’s the backbone of our process I will have another card to play to have server updated.

  15. The only argument I can see against dropping the support for PHP4 is that a lot of hosts still provide it as the ‘primary’ scripting engine (with PHP5 enabled by using different extensions for instance). With the announcement that PHP4 is going EOL however I don’t think that will be the case for much longer.

  16. Do it. PHP4 is a dinosaur that is a development hinderance going forward. I’ve been affiliated with Gallery for a number of years now, and they were very much on board with GoPHP5, and I’m totally with them on it.

    Anyone still developing on PHP4 in 2008 is seriously in need of some shock therapy. (I can understand people who still have to run legacy apps, but no new development – it’s just stupid at this point.)

  17. You essentially already dropped PHP4 support in 1.1RC2 – we had to switch to PHP5 – to avoid those Segment Faults (and lack of output) when loading bug notes – to make it work

  18. > Well, our server is only visible on the intranet, and so we don’t see
    > reasons to update any system software… if all applications work
    > smoothly. That’s simply a matter of administration and costs.
    >
    > Now, when you drop the php4 support, we are forced to update. If we
    > had to review Mantis, this would be a “minus”…

    It may be comforting to users to offer a final php4 compatible release which will have no feature enhancements/fixes and just provide critical security updates – like the php4 code base from php.net – but if a user is using mantis in an intranet environment and doesn’t upgrade for critical updates then the last released php4 supported version should suffice.

    I don’t see dropping php4 support in that scenario as a “minus” since not upgrading implies you are already comfortable with the feature set provided – or cannot cost justify the time to invest in upgrading for newly provided features.

    If you are investigating mantis as a new solution for issue tracking, you would run into the same scenario of investigating its requirements for a new installation. Even if mantis continued to support php4, you would look at the most stable *supported* version of php – and since php4 is EoLed, you would most likely not consider php4 but consider php5 as part of the requirements for bringing mantis into your organization.

  19. we may have to upgrade php on our server, but go for it! If we can’t upgrade we will have to live with the current mantis, and we accept that

  20. It is all very well to say that 1.1.0 will be the lst to support PHP4….

    Don’t really care all that much, except for the fact that I just spent over 3 hours trying to get 1.1.0 working on a server with PHP4 on it and it failed to work due to an icompatability.

    Q. Was this release actually TESTED on PHP4.4 before it was released?
    I’m thinking no…..

  21. Cam, the incompatibility discovered so far was one that slipped through in one of the latest change. Unfortunately since the official bug tracker uses PHP 5 and the machine that was used in final testing with set to PHP 5 for 1.2 developed (the mistake was not switching it back to PHP 4.x), the bug slipped through.

    The fix can be found in the following issue that will be fixed in Mantis 1.1.1.
    http://www.mantisbt.org/bugs/view.php?id=8681

  22. I ran into this, too, and stuck with PHP 4.0 for the time being. Fortunately, it was a simple matter to hack the offending line. I’m assuming you’re all talking about the stripos call in config_defaults_inc.php. Changed it to

    $t_soap_api_path_pos = strpos( strtolower($t_path), $t_soap_api_path );

  23. FYI: Solaris 10 update 4 (update 5 is expected in september) companion CD delivers PHP4. The “cool tools” team at Sun have a PHP 5.2.4 package and I have that installed. I’m uncertain as to the availability of this for x86, since I run on SPARC.

  24. I am using Mantis on a certified RedHat Enterprise Linux Server 5 system. The latest update of PHP inside RHEL5 is version 5.1.6-20. So I don’t have any problems with PHP5 but right now requiring PHP version 5.2 is a problem. I hope this will not be a problem by the time Mantis 1.2 is released. If I would have to choose between upgrading PHP with a non certified version or not upgrading Mantis I would do the last.

  25. Well, many many web hosts out there are still running PHP4. Even many major ones. My 1and1 site is php 4.3.9, Media Temple is 4.3.9, etc. There are plenty of other hosts that are still on php4. Probably the majority.

  26. I am heartily in favor of requiring PHP5, and more-so of using some of the much better OO design features available in PHP5.

    I have, myself, switched to PHP5-only coding a year or so ago.

Comments are closed.