TranslateCI makes human translations for your Laravel app as easy as using Git. Just push your code, and TranslateCI will take care of the rest. It scans for untranslated phrases, and uses professional human translators to support over 70 possible language pairs. When the translations are done, usually in less than 24 hours, TranslateCI makes a PR back to your repository. Check it out today!
The past few weeks we released several new packages: laravel-sluggable, laravel-robots-middleware, laravel-glide and pdf-to-text. These packages have in common that they all require PHP 7. Because there were several reactions and questions about this, I'd like to shed some light on that decision.
I expect that lots of developers will make the move to PHP 7 in the coming year. Sure there will always be legacy projects that'll never see an upgrade, but it makes no sense starting a greenfield project in PHP 5.X. The performance benefits are just too good. On the package side I expect that some widely used packages will make the jump as well. Jordi Boggiano has already announced that the next version of Monolog targets PHP 7. Also keep in mind that active support for PHP 5.x is coming to end this August (or at the latest December).
Not only developers will make a quick move to PHP 7. The speed benefit is quite interesting for hosting companies as well. A speedier PHP version means a machine can host more sites. There quite a few hosting companies that already made the jump and are offering PHP 7 support.
When we work on projects at Spatie we have to solve a lot of problems. When we solve a problem in way that the solution can be used in future projects, we create a package. So we create these packages primarily for our own future projects. We decided that from now on every greenfield project wil be a PHP 7 one. So it makes sense that our new packages would require PHP 7 as well. By doing so we can make use of the latest new features such as the scalar type hints, return types, anonymous classes and the null coalescing operator. At some point all our projects will leave PHP 5.6 behind. The earlier we won't have to deal with PHP 5.X code anymore the better.
I'm well aware that requiring PHP 7 will hurt the popularity of our packages in the short run. But popularity is not our main goal. People who are using the latest and greatest version of PHP can benefit from our work. And I hope others will be nudged a bit towards PHP 7 by our decision.
(EDIT: we won't change the requirements of our older packages. PHP 7 will only be required when we create a new major version.)
Follow me on Twitter. I regularly tweet out programming tips, and what I myself have learned in ongoing projects.
Every two weeks I send out a newsletter containing lots of interesting stuff for the modern PHP developer.
Expect quick tips & tricks, interesting tutorials, opinions and packages. Because I work with Laravel every day there is an emphasis on that framework.
Rest assured that I will only use your email address to send you the newsletter and will not use it for any other purposes.
@freekmurze you do you. Everyone else should just enjoy and be thankful for all you and @spatie_be share. I tip my hat to you good sir!
A guy do something for free. Suddenly he gets tons of obligations to third screaming parties. Today open source world.
Those are your rules, not mine. For me, it makes zero sense investing time to keep things compatible with version of the framework/PHP that I don’t use.
Those are not my "rules" nor I imply that you should follow them as I'm a package maintainer myself. Those are just observations (especially about the general treatment of the LTS when comparing the Laravel and Symfony ecosystem).
Let me state this again. I'm not asking anybody to spend time on something that doesn't benefit them. I'm just comparing the situation in two of the biggest PHP ecosystems and how each treats its LTS releases.
I think no one should be this entitled to demand anyone else to spend time on something that doesn't benefit them.
In addition anyone in need of patching a (tagged) version in a package can contribute the fix. No branch is needed for that.
I don't know the context of this twit, but there should always be an actively maintained branch that supports the latest LTS, otherwise it makes the LTS kinda pointless. In the SF ecosystem I haven't yet seen a package written from scratch that doesn't support the latest LTS.
Most of spatie's packages do have an MIT license so for those who want to support an older PHP version. Just fork it and make it compatible yourself.
Hi, Nuno. We'd love to hear how we can better your experience. You can share more detailed feedback through the Management Console by clicking on the 'Feedback' button in the bottom left-hand corner. 👍 ^CM
I remember being one of those people when I first started. When you changed a PHP version requirement. Looking back, I was a dick, and you forced me to up my game. So I appreciate the stance you have.
Did you ever get my postcard?
Tbh i like it since it forces people to stay with the times and invest those couple of hours in project upgrades!
The only thing I don’t like is that @AWSSupport only supports MySQL 5.6 compatibility with their Serverless offering so I always have to remove or adapt any json fields and make sure queries work :(… unless I get a “serverless” server.
Only issue is that currently, we cannot switch to php 7.4 since ionencode Currently doesn't support it. But hopefully soon. 🤞
