I’m due to replace a few machines over Xmas, and a switch to 13.1 seems to be a good idea since I already have to manually install Apache2.4 on the 12.3 setups, and it’s nice to see that PHP5.4 is being shipped with it in 13.1 but my next problem may be that for practical reasons I don’t want PHP.5.5 on the systems so need to lock that down in future. What is the best way of managing versions at this level? With essentially time consuming changes happening in the likes of PHP and some of the other tools we use, while we used to complain that distros were not keeping up quickly enough, nowadays it’s changing too fast which is becoming the problem. I’m still running machines with PHP5.2 on 12.3 simply because there are not enough hours in the day to rework that code base to bring it up the ‘e_strict’ standards in PHP5.4 … and some systems are still on ASP because there is no time to convert them to PHP 
13.1 ships with 5.4.20 and that will not be upgraded to 5.5 ever, there only will be bug/security fix updates.
For 13.2 I don’t know (this will likely include a higher version though), but you can lock versions in YaST->Software Management or by using “zypper addlock” (see “zypper help addlock”). In this case a lock on the “php5” package should suffice.
Those locks should be respected even when upgrading to a newer openSUSE version with “zypper dup”. If you do the upgrade via an installation medium though, I don’t think the locks will stay in place.
Another (better) possibility would be to install the packages from some other repository (if available in the versions you want; if not you would have to create your own, on OBS perhaps). Those packages won’t be changed back to the shipped versions automatically anymore.
You could just build the already available 12.3 (f.e.) packages for a newer openSUSE version in your home repo.
That’s how I would do it.
Thanks that was just the sort of insight I was short of!
I got caught out with 12.3 changing versions hence the question, and I think I can see a way forward. Just sticking with 13.1 for a couple of years will probably do the business.
FYI: 13.1 will be the next version supported by the Evergreen project, so it will still get security updates for a while after its official EOL as well (until November 2016 according to current plans).
When we are still running systems that are ten years old, this is too short a time-frame for an LTS platform. What is needed is something with a 5 year cycle rather than just a couple. Heck we are still maintaining W2k systems simply because there is no money around to rewrite all the software to work with later builds of windows - no the existing software will not run! The nice thing these days is that Linux IS now an acceptable alternative path and a couple of the machines on my upgrade list are currently W2k or XP … And it will probably be another 10 years before they are changed again … they are sitting on private networks with no outside access so don’t get updated at all unless there is something pressing 
But somebody has to do that long time support. You can’t really expect 5 years support (or even more) from volunteers doing it in their spare time.
You can have support for upto 10 years (AFAIK), if you use SLES (or some other commercial distro) though…