php7.0 why removed from the ports?

bagas

bagas

Hello.
Why removed from the ports php7.0?
This is all wrong!
Forcefully translate to newer versions of php.
My site does not support 7.1 / 7.2!
Officially php7.0 is supported in php.net
The policy produced in the last 2-3 years by the ranks of the FreeBSD project management is very frustrating!
 
Why without warning php7.0 is automatically updated on php7.2 ?!
In /usr/ports/UPDATE nothing is said about automatic php7.0 update on php7.2!
Politics is a failure for you!
 
It doesn't really matter if there's a bug fix release, 7.0 branch is oficially EOL and not supported. Looking at the lang/php70/Makefile log, deprecation notice was added more than 2 months ago.
 
All this is an excuse, okay not so not.
The popularity of the freebsd system is small, and with such incidents it will completely fall into a hole.
 
bagas said:
All this is an excuse, okay not so not.
The popularity of the freebsd system is small, and with such incidents it will completely fall into a hole.
Click to expand...
This has nothing to do with FreeBSD. If you want to complain then please direct that to the PHP developers. All FreeBSD did is follow their lead.

(edit)

Here is the list of supported PHP versions, as shared by the PHP team themselves:

http://php.net/supported-versions.php

I quote: 7.2, 7.3 where 5.6 and 7.1 only get security fixes (time of writing obviously). You'll notice that because of this lang/php56 still exists, even though it officially went EOL.

For the record: I can perfectly understand your frustration, but as mentioned: you're barking up the wrong tree here. It is for this reason (the upgrade cycle) why I never bothered to get deeper into PHP and stuck with Java & ASP.NET. Those projects don't pull unprofessional stunts like this.
 
I know up to what day the release lives!
There is an official release php 7.0.33, why it was not added?
why then did not close php5.6?
 
My sympathies to you for your frustrations. php71 has been around for something like 2 years now, so this shouldn't really be a big surprise. For whatever it's worth, I hope it might reassure you to know that I've had no trouble migrating between 7.0, 7.1, and 7.2. All my php scripts can now run on any version from php5 to php72, after only a few small changes that were needed when I made the initial jump from php5. The biggest difference I've noticed since then is that the newer versions can run much much faster than the older ones. Upgrading is well worth whatever trouble it might entail.

If you have an older server with php70 installed on it, I think you should be able to make your own packages using the pkg create and pkg repo commands which you might then be able to install on other systems using pkg add. If you're really determined or really need to stick with 7.0. But why not just go ahead and get the upgrade out of the way now? That is what I would sincerely advise you to do.
 
bagas said:
I know up to what day the release lives!
Click to expand...
Apparently not.

There is an official release php 7.0.33, why it was not added?
why then did not close php5.6?
Click to expand...
Simple. Security support for 5.6 will last until 31 December. The PHP 5.6 port will be removed 1 January. Security support for 7.0 ended 1 December. The port was removed on 3 December.

If you have complaints about the PHP EoL dates, complain to PHP.
 
To be honest it is a bit frustrating that the port is removed immediately as soon as official support ends. If you have a real need to run an old version on some private system, you're left having to build manually from source rather than just having the port stay around a while with a big unsupported warning. I'm sure I've come across many ports that are effectively unsupported and no longer developed (but without such an official timeline as PHP) but are still in ports and widely used.

This does appear to be a bit of a mess from PHP's side though. They seem to have released an update after their own end-of-life date.

Having said that, I've moved code from 5.6 to 7.x several times without much issue. The last one I remember was an old PDF generator (third party library); All I had to do for that was change some ereg calls to preg and remove calls to magic_quotes functions. I really can't believe that there is much work required to make code that works on 7.0 work correctly on 7.1+.
 
usdmatt said:
you're left having to build manually from source rather than just having the port stay around a while with a big unsupported warning.
Click to expand...
What's stopping you from checking out an old ports tree?
 
To be fair, I didn't think of using an old copy of the ports tree. PHP is fairly standalone as long as you avoid things like suphp so it may be reasonably straight forward to just build php from an old port and use the most recent tree for everything else.

Obviously for your own project I would suggest making it work on 7.1. I really can't see 7.0->7.1 being difficult. It's a bit more awkward if you're upgrading a server used by third party applications where it's not your responsibility to update their code.
 
usdmatt said:
To be fair, I didn't think of using an old copy of the ports tree. PHP is fairly standalone as long as you avoid things like suphp so it may be reasonably straight forward to just build php from an old port and use the most recent tree for everything else.
Click to expand...
Yep, exactly. I've done this before with a few other ports (not PHP) when the latest version had a bug and failed. If you have your own repository it's fairly easy to downgrade one or more ports or update selectively.

usdmatt said:
Obviously for your own project I would suggest making it work on 7.1. I really can't see 7.0->7.1 being difficult.
Click to expand...
Updating from 7.0 to 7.1 should be relatively easy. Much easier than the jump from 5.6 to 7.0 was for example.
 
I recommend jumping to 7.2 right now. It runs faster and php.net has already released 7.3.0. Syntax wise new things are being added but old things don't change much. Agreed that the jump from php5 to php7 was a bigger jump, but hardly even close to being as bad as I had feared it would be.
 
Phishfry said:
So Janurary1st will be lots of fun. Lots of old broken ports to fix...
Click to expand...
Everything that specifically depends on the removed ports will get removed too. Other depending ports shouldn't be an issue, the default was set to 7.1 some time ago.
 
php70 only had 79 run dependencies so there is more loss for the upcoming php56 deletion.
Plus it looks like PHP upstream did an out of band update php56 too. Well 24 days before RIP date.
Just looking at the ports tree that is a mess having ports for php56 php70 php71 php72 php73 (and all their modules)
 
I'm the one who deletet PHP 7.0 :)
As others have said, PHP 7.0 is EOL. It does not matter if an update comes out after that. The support for PHP 7.0 ist closed.
It makes no sense to keep something dead in the ports. We are too few and too busy in the ports. You can check when which PHP version ends. Why are you complaining? We're busy checking all PHP 7.2 and PHP 7.3 ports. On January 1, many ports will be deleted that only work with PHP 5.6. That will be fun. All of a sudden everyone will be totally surprised.

If you need PHP 5.6, you can build your own tree with portshaker.

Edit: And if you look in UPDATE, you will see that you have always been informed about the change of the default version !!!
 
joneum@ said:
It makes no sense to keep something dead in the ports. We are too few and too busy in the ports.
Click to expand...
Also worth noting, ports are a community effort. Nobody is being paid to actively maintain ports, it's all voluntary. FreeBSD is not like RedHat who has hundreds of developers working for them fixing and maintaining software long past its EoL date (RHEL7 for example has PHP 5.4 as default).
 
Yes, ports are a community effort but if important ports like PHP, Perl, X11 etc. were actually left in the hands of the "community" we would have none of them available or we would have multiple competing incompatible versions of them and a huge mess. This is why these important ports are in the hands of select individuals and small teams that can be trusted a bit more than your average FreeBSD user and have an understanding what "EOL at upstream" signifies and aren't afraid to make unpopular decisions like this one here.
 
You must log in or register to reply here.
Back
Top