Server Side Versions

With client side code the version that is supported is determined by which browser your visitors are using. For the server side languages you have more control. Let's consider a typical configuration for a personal or small business web site. Typically the web server will be Apache and the scripts will be written in PHP and use a mySQL database. In the rest of this article I will refer to those specific languages simply for convenience as those will be what many readers are actually using. If your particular configuration is different then simply substitute your web server, programming language and database for those in the discussion as the actual languages make no difference.

If you have dedicated or VPS hosting then you will have complete freedom of choice when it comes to when you upgrade to a more recent version for each component.

With shared hosting you will have no control over which version of Apache is being used as that is shared between everyone on the server. You will also be unlikely to have control over which version of mySQL you can use as that too will likely be shared (although if the host keeps the databases on a different server to the hosting (ie. you don't specify 'localhost') then there may be a possibility of choosing between database servers running different versions of mySQL. It is with PHP where you are most likely to have a choice as it is relatively easy for the hosting provider to install multiple versions of PHP and let you choose between them.

So in those cases where you do have the ability to choose, how do you decide which version to run? There are in fact several things you need to consider. The place to start is to look at which version is considered to be the current version. In most cases you will not want to run a version more recent than that as those versions will still be in development, subject to change and may contain bugs. You can determine the other end of the range to consider by looking at the dates at which support for specific old versions are to be dropped. For PHP the easiest way to find these things out is from php.net/releases which not only tells you when various versions of PHP reached their end of life dates (for example 5.3 reached end of life on 14th August 2014 - when the last sub-version was released) it also tells you when support for prior versions has been discontinued (PHP 4 has not been supported since the end of 2007 - even though there were two more versions of PHP 4 after that date). Obviously you will not choose PHP 4 as the version to use and if you will try to avoid 5.3 and earlier if you can.

Another consideration when you have existing code is which versions that the code will work with. This is where having one or more testing environments is important. You need a testing environment that is running the same versions of Apache, PHP and mySQL to test on as you have running on your web site. This allows you to make sure that your code actually works before you upload it too the web. You can have error messages turned on in your test environment so you can see what is causing errors while having it off on the live hosting so that if errors do somehow make it to the live server that others cannot tell what the cause is so as to exploit any potential security hole more easily. So most of the time you will want to have your test environment and hosting running the same versions of Apache, PHP, mySQL etc so that you can test things properly before they go live. When you are ready to upgrade to a new version you will need to upgrade your test environment first (or create another one) and test everything to make sure that it will still work before upgrading the version on your live site. Any code changes needed to fix problems due to the upgraded version will need to be uploaded at the same time.

If you are simply using someone else's code then you probably don't need a test environment so instead of having to consider keeping two environments that you control in step you will need to consider keeping your live site versions in the range that the code author has indicated that their code is compatible with.

Actually switching from one version to a more recent one will probably involve a lot of work with testing code and installing the new versions. For this reason you will probably not want to upgrade each and every time a new version comes out. If you installed say 5.5.2 on both your test and live environments then you will likely stick with that version on your test environment while upgrading your live server to 5.5.3, 5.5.4 and so on as these sub-versions may be bug fixes that you will need to have installed to prevent exploits of newly discovered security holes. With shared hosting your hosting provider will even do this for you and not give you the choice between sub-versions. Your test environment is only accessible to you and so the only time you will need to upgrade to a new sub-version is if your code is directly affected by the problem one of these patches is intended to fix.

Every so often you will need to upgrade to a more recent version as the version you are using passes its end of life date and the point at which it will cease to be supported approaches. You need to pay particular attention to the advanced notice of when support for the version you are currently using is expected to be dropped. Long before that date you need to get an upgraded test environment and retest all your code to make sure that it will work on a newer version so that you can switch to that version well in advance of the drop date.

It isn't even full versions that can have support dropped. There can be advanced notice of commands that are expected to be dropped from a language at a future date. When this happens the command is identified as deprecated which simply means that the command should now be considered to be obsolete and that it will be removed in a future version. When you receive such a notice, replacing all of the deprecated code should be added to your 'to do' list to be actioned as soon as possible. The longer it is on your list without being done, the more urgent making that change will be. You need to make sure that you get the change made and tested long before that command actually gets dropped or you risk being forced to keep running a no longer supported version simply because your code will no longer run on any supported version. An example of this at the time of writing are the PHP commands prefixed mysql_ which were flagged as deprecated long ago and where any code using those calls should have by now been rewritten to use either mysqli_ calls or the new PDO interface. In this case testing your code becomes really easy since you only need to comment out one line in your PHP configuration to remove support for those commands in your test environment so as to test to make sure your code will still work when that line gets deleted.

Which versions you run on the server is at least partly if not entirely under your control and what has been mentioned here are some of the things you need to keep in mind regarding which versions you run and when you decide to upgrade.

go to top

FaceBook Follow
Twitter Follow
Donate