Laravel 5.1 with LTS is released(laravel-news.com)
laravel-news.com
Laravel 5.1 with LTS is released
https://laravel-news.com/2015/06/laravel-5-1-released/
10 comments
http://laravel.com/docs/5.1/releases#laravel-5.1
In previous versions of Laravel, encryption was handled by the
mcrypt PHP extension. However, beginning in Laravel 5.1, encryption is
handled by the openssl extension, which is more actively maintained.
Annoyingly I just set up a Laravel install for evaluation on OSX and wrestled with getting mcrypt to work!
IM(not so H)O, wrestling with Mac is not worth anyone's time. Using Vagrant or a similar VM setup will get you in an environment much more like "production" and with fewer headaches caused by mac's special snowflake OS.
(I personally use Mac as my host OS, because I love it, except when it comes to installing server software).
(I personally use Mac as my host OS, because I love it, except when it comes to installing server software).
Chris, I agree with you completely. I also suggest this beaut: https://github.com/fideloper/Vaprobash wink wink, hint hint.
An idempotent provisioner would be a better option. Ansible is my favorite.
I've tried Ansible and Puppet, but I just never could get used to them or like them. I like the shell provisioner because I know EXACTLY what it's doing. I can provision a server myself, I have the knowledge and understanding to. I can type up the commands in a bash script to provision it faster than I could learn exactly what Ansible or Puppet or Chef are doing when I tell it to install Nginx.
I get completely where you are coming from, the reason that I eventually got the hang of Ansible is because if you do it right (I mean using ansible's modules over scripts/commands) it adds the ability to rerun your ansible playbooks (think of them like those bash scripts) multiple times on the same cluster/node/server without worrying something will change because you run them more than once. Also bash on it's own has no templating feature, or easy way to check if something has already happend. And after a while the whole systems starts making sense.
I can only imagine your current bash-scripts are awesome and do tons of stuff for you, but I'd really like to suggest you give ansible another go, and ignore the different files for roles/vars/tasks in the beginning, just dump everything into one playbook, like your bash scripts do currently.
I can only imagine your current bash-scripts are awesome and do tons of stuff for you, but I'd really like to suggest you give ansible another go, and ignore the different files for roles/vars/tasks in the beginning, just dump everything into one playbook, like your bash scripts do currently.
I've made that too: https://github.com/vagrant-ops/vagrantops (although work in progress, and I have some sneaky/evil/delicious plans for it)
Sorry to hear that.
If mcrypt is such a pain for OSX users, I might offer to refactor some other frameworks' libraries to use openssl in the near future.
Why mcrypt sucks: https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcr...
If mcrypt is such a pain for OSX users, I might offer to refactor some other frameworks' libraries to use openssl in the near future.
Why mcrypt sucks: https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcr...
> If mcrypt is such a pain for OSX users
It's not, if you're using Homebrew (which you should be). `brew install php56-mcrypt` and you're done.
It's not, if you're using Homebrew (which you should be). `brew install php56-mcrypt` and you're done.
I am using homebrew but it definitely wasn't that simple. I think it was because my OSX (for some reason) wasn't using the right PHP version and so installing mcrypt from homebrew didn't have any effect until I reconfigured apache.
Just upgraded a large 5 to 5.1 codebase in under 5 minutes (4 of that was composer ;) ) and everything passed functional testing.
Outstanding work and the new docs are an excellent improvement.
Outstanding work and the new docs are an excellent improvement.
This is a great idea. My main gripe (on a very short evaluation) with Laravel is that the default application that artisan gives you comes with a lot of files dotted around the directory structure. With something like Rails these tend to be locked away in a gem and so when using CTRL+T (or similar) you get a lot of cruft popping up.
That said I do like the things that Laravel gives you out of the box like auth and the command pattern.
That said I do like the things that Laravel gives you out of the box like auth and the command pattern.
`php artisan fresh` removes a lot of the default files. They're intended as a starting point for new users but are entirely removable.
This command has been removed since like half year ago. https://github.com/laravel/framework/commit/37ebc7ecc693405a...
Heh, apparently it's going away. Again.
https://github.com/laravel/framework/pull/9161
https://github.com/laravel/framework/pull/9161
Looks like the Fresh command wasn't registered in the ArtisanServiceProvider. I have a PR open to fix this. https://github.com/laravel/framework/pull/9161
Nope, looks like the command should have been removed anyway... https://github.com/laravel/framework/pull/9161#issuecomment-...
How many other Frameworks offer LTS releases?
Plenty are mature enough to offer this, but commercial backing must be hard to come by.
Plenty are mature enough to offer this, but commercial backing must be hard to come by.
Leaving the PHP world, Django does:
https://docs.djangoproject.com/en/1.8/internals/release-proc...
staying in PHP world, Symfony2 does http://symfony.com/doc/current/contributing/community/releas...
Regarding Python, Django does LTS releases.
Too bad it is still slow as a glacier.
This comment makes no sense. Well, it makes sense, but I don't believe it comes from someone who's really considered what they're saying.
First, it's PHP. Same situation with Ruby and Python. All generally slow as a glacier (obvious exclusions being different implementations of said languages).
Developers' focus on code speed is ridiculous (is that too strong a word?) due to relative inexpensiveness of "hardware" and the "fact" (yep, fact) that code is for building value.
In most cases, that value is provided via an automated service. Speed of that automation is typically not critical (obvious exclusions being something like medical equipment or stock trading, or making people wait ridiculous seconds after clicking a button. Please don't Well Actually™ me to death with pedantry).
First, it's PHP. Same situation with Ruby and Python. All generally slow as a glacier (obvious exclusions being different implementations of said languages).
Developers' focus on code speed is ridiculous (is that too strong a word?) due to relative inexpensiveness of "hardware" and the "fact" (yep, fact) that code is for building value.
In most cases, that value is provided via an automated service. Speed of that automation is typically not critical (obvious exclusions being something like medical equipment or stock trading, or making people wait ridiculous seconds after clicking a button. Please don't Well Actually™ me to death with pedantry).
Great response, and you make a great point - focus on coding speed is a great reason to choose Laravel. It's also hugely popular and now with it's LTS, it's going to be around for a while.
For me personally, I was a ZF 1.x guy; when I started a new project I chose Laravel, and it was a dream - crazy zippy (compared to ZF). But as I started to do more with it, I started to need to reduce my feature set, implement performance "features" just to retain a measure of speed.
Is 5.x faster than 4.x? Sure. Does it include batteries and the kitchen sink? You bet. Do I still prefer a faster framework like Phalcon and implement the features I miss myself? Damned skippy.
For me personally, I was a ZF 1.x guy; when I started a new project I chose Laravel, and it was a dream - crazy zippy (compared to ZF). But as I started to do more with it, I started to need to reduce my feature set, implement performance "features" just to retain a measure of speed.
Is 5.x faster than 4.x? Sure. Does it include batteries and the kitchen sink? You bet. Do I still prefer a faster framework like Phalcon and implement the features I miss myself? Damned skippy.
We're doing 2k req/s with Laravel for one of our API services. In order to maintain ~150ms of latency, this takes us ~14 c3.2xlarge boxes in a load balanced environment. We've done a lot of tuning to squeeze this much out of the boxes (nginx + php fpm) but ultimately I feel pretty let down by laravel/php. ~150 req/s per c3.2xlarge box is very disappointing. I'm hoping to migrate off and go with something like Scala+Play or even Go perhaps.
Don't walk, RUN if you can to HHVM. Like you, I was running on amazon. Sure PHP runs at scale but then you have to load-balance. But come on, we had 20 servers at a cost of ~$6k a month. Thats just for the front-end also.
In August, I switched to HHVM and I was able to shrink down to a single server. Now I'm running 3 for things like redundancy. My bill? Around $1500 a month, big difference. No wonder Etsy, Wikipedia, Baidu and others have switched over.
Not only this, but 3.8 is coming with increased performance over 7. Not only RPS but also latency as well. I run an ad server and the latency DROP was huge compared to PHP.
Oh and for the backend application. Moving to HHVM it definitely feels much snappier than PHP. In some cases, you can see the difference. I don't regret moving to HHVM. Very very doubtful I'd move back to PHP 7.
My only 2 complaints are that Postgres and zeroMQ drivers are 3rd party extensions. There is talk of Postgres coming in house. I just wish more people could petition for ZeroMQ to be included.
If you do go to HHVM. Maybe it may be worth moving from Laravel to Slim (3)? You may get a boost due to the lower framework size? I know I did when going from Codeigniter to Slim 2.
In August, I switched to HHVM and I was able to shrink down to a single server. Now I'm running 3 for things like redundancy. My bill? Around $1500 a month, big difference. No wonder Etsy, Wikipedia, Baidu and others have switched over.
Not only this, but 3.8 is coming with increased performance over 7. Not only RPS but also latency as well. I run an ad server and the latency DROP was huge compared to PHP.
Oh and for the backend application. Moving to HHVM it definitely feels much snappier than PHP. In some cases, you can see the difference. I don't regret moving to HHVM. Very very doubtful I'd move back to PHP 7.
My only 2 complaints are that Postgres and zeroMQ drivers are 3rd party extensions. There is talk of Postgres coming in house. I just wish more people could petition for ZeroMQ to be included.
If you do go to HHVM. Maybe it may be worth moving from Laravel to Slim (3)? You may get a boost due to the lower framework size? I know I did when going from Codeigniter to Slim 2.
We ran some experiments with HHVM last year. Unfortunately, some random library that has a random dependency was failing on HHVM. The surface area for this type of incompatibility is a bit too much for me to bear.
PHP once had its place to make .html files dynamic. Unfortunately, the ease of making this happen accidentally turned PHP into what it is today. Beyond this, there isn't much merit to the language, the frameworks, or the ecosystem at all.
We're certainly running. But rather than stopping at HHVM, we're dropping PHP altogether.
PHP once had its place to make .html files dynamic. Unfortunately, the ease of making this happen accidentally turned PHP into what it is today. Beyond this, there isn't much merit to the language, the frameworks, or the ecosystem at all.
We're certainly running. But rather than stopping at HHVM, we're dropping PHP altogether.
Have you looked at hhvm recently? A lot has changed since then and things have gotten better.
Although like you, I am eyeing golang as well. But not got any work scheduled until the latter part of this year.
Although like you, I am eyeing golang as well. But not got any work scheduled until the latter part of this year.
I'm really glad to see I'm not the only one that feels the performance drop is painful, nowadays the only thing I do backend are API's, thus a lot of the features (like blade) are superfluous to me. I hope Lumen will kind of fix this, and be the perfect go-to framework for API's done in PHP.
Having said that, looking at the future it would make a lot more sense to switch to a different language altogether, it's a same my current employer only wants to run php backend (because it's 1 command to install, I know bad reason, but they don't want to support other languages). Why exactly are you looking at Scala or Go? I kind of get Scala (but I'd personally rather opt for Clojure), but why Go? Purely because it's much more performant than php? Doesn't this has to do with the lacking of such a full-featured framework like laravel?
Having said that, looking at the future it would make a lot more sense to switch to a different language altogether, it's a same my current employer only wants to run php backend (because it's 1 command to install, I know bad reason, but they don't want to support other languages). Why exactly are you looking at Scala or Go? I kind of get Scala (but I'd personally rather opt for Clojure), but why Go? Purely because it's much more performant than php? Doesn't this has to do with the lacking of such a full-featured framework like laravel?
Yeah, that's the same conclusion that I came to myself. In my past experience the bottleneck is almost always the database but throw in Laravel and it takes some serious hardware just to stay afloat.
I recently started thinking about switching languages and like everyone I know I started with Node.js first. I found myself rapidly infuriated with it and decided to try out Go. I wrote a quick S3 upload demo app just to grok it and I was thrilled with the results. Scala outperforms Go but I like Go a little more for rapid app dev. If you decide to take the plunge do let us know how it goes!
I recently started thinking about switching languages and like everyone I know I started with Node.js first. I found myself rapidly infuriated with it and decided to try out Go. I wrote a quick S3 upload demo app just to grok it and I was thrilled with the results. Scala outperforms Go but I like Go a little more for rapid app dev. If you decide to take the plunge do let us know how it goes!
Hey, that's really interesting! Is that laravel specific or is that general with PHP (frameworks) in general? Would love to know more about that and your setup/tuning.
(Also wonder how well php7 will help that out).
I think at that scale, it's certainly reasonable to try getting away from PHP.
(Also wonder how well php7 will help that out).
I think at that scale, it's certainly reasonable to try getting away from PHP.
Have you tried HHVM?
For any nontrivial service that wants to build a large audience, something with the glacial performance of Laravel (and I use Laravel, so I'm not completely knocking it) has the downside that things you would normally do when much more mature crop up earlier. Like having to worry about horizontal scaling, or rewriting parts of your app in another language.
I'm not quite sure where L5's performance gets sunk so badly, but it really is a lot slower than earlier variants of the framework. About the only thing slower is Rails, really!
... and unlike Rails, Laravel hasn't had the stability and ecosystem to make those things really easy. Hopefully this LTS plan will change that a wee bit, but we'll see.
I'm not quite sure where L5's performance gets sunk so badly, but it really is a lot slower than earlier variants of the framework. About the only thing slower is Rails, really!
... and unlike Rails, Laravel hasn't had the stability and ecosystem to make those things really easy. Hopefully this LTS plan will change that a wee bit, but we'll see.
Have you seen any benchmarks? Route and config caching is a huge improvement in 5.0
Yes, I have seen 5.0 benchmarks and even run some boom tests myself (admittedly nothing in a terrible amount of depth). The one I can cite offhand is this one http://blog.a-way-out.net/blog/2015/03/27/php-framework-benc...
I'd be happy if you could link the benchmarks you have seen that demonstrates performance increases.
I'd be happy if you could link the benchmarks you have seen that demonstrates performance increases.
Probably not when it's running on HHVM, it has 100% integration with it.
Why space? Why not tabs? Why do I need to press 10 times space instead of 2 times the tab?
If you're pressing spaces to align indentation, you're doing it very, very wrong.
Because that's what the PHP community decided with PSR-2. It's an endless debate. :)
As interesting as LTS support is, 2 years is frankly very short.
I'm used to thinking of LTS support in terms of 4-5 years. I suspect everyone else is too and Laravel is going to piss off everyone who doesn't read the fine print.
I'm used to thinking of LTS support in terms of 4-5 years. I suspect everyone else is too and Laravel is going to piss off everyone who doesn't read the fine print.
> I suspect everyone else is too and Laravel is going to piss off everyone who doesn't read the fine print.
If I'm on a project where LTS matters I'd not be doing my job if I didn't read the small print.
If I'm on a project where LTS matters I'd not be doing my job if I didn't read the small print.
I'd say that to the people that complain about MongoDB's default configuration in the early days but many people feel perfectly justified in that position.
It's actually 2 years of updates + 3 years of security updates.
A web framework that no longer is accepting bug fixes isn't really supported. So yes, its only supported for 2 years.
https://php.net/supported-versions.php
PHP versions offer 2 years of support + 1 year of security fixes. So it doesn't really make sense for a PHP project to offer longer support.
PHP versions offer 2 years of support + 1 year of security fixes. So it doesn't really make sense for a PHP project to offer longer support.
1) They aren't lining it up with PHP version support which means if that was their justification, they didn't think it through at all.
2) That doesn't make it long term support.
3) > Since originally launching in 2011, Laravel has always followed the “release early, release often” mantra which is popular in open source applications. With the historic rise in popularity of the framework, it was time to start focusing on the needs of large organizations and mission-critical applications that need security fixes but can’t upgrade quickly. Laravel 5.1 will now include 3 years of security fixes.
The logical way to have handled this if that was the reasoning would have been to say "Laravel 5.1 will be supported until Aug 2017 to line up with the PHP release cycle and provide a stable platform for large organizations along multiple levels of their tech stack.
As each version of PHP is released, we will release a LTS support version of Laravel in sync with PHP's cycle within X months."
That isn't what they did and that is not what they communicated in any, way, shape or form. It doesn't line up with PHP's release cycle, it doesn't have the coverage needed to be truly LTS. It isn't like PHP has breaking changes in every point release.
2) That doesn't make it long term support.
3) > Since originally launching in 2011, Laravel has always followed the “release early, release often” mantra which is popular in open source applications. With the historic rise in popularity of the framework, it was time to start focusing on the needs of large organizations and mission-critical applications that need security fixes but can’t upgrade quickly. Laravel 5.1 will now include 3 years of security fixes.
The logical way to have handled this if that was the reasoning would have been to say "Laravel 5.1 will be supported until Aug 2017 to line up with the PHP release cycle and provide a stable platform for large organizations along multiple levels of their tech stack.
As each version of PHP is released, we will release a LTS support version of Laravel in sync with PHP's cycle within X months."
That isn't what they did and that is not what they communicated in any, way, shape or form. It doesn't line up with PHP's release cycle, it doesn't have the coverage needed to be truly LTS. It isn't like PHP has breaking changes in every point release.
2 years for bug fixes, 3 years for security fixes
[deleted]
Being the first release offering LTS is fantastic news for the community.
We've been using it with Cachet (https://github.com/cachethq/cachet) for a couple of weeks. Mainly it was to make testing our API easier, the new PHPUnit extensions are so freaking amazing - it makes unit testing a dream.
Other than that, other cool features I like are the LTS, dropping of the mcrypt extension requirement and also the broadcasting feature (which is worth checking out btw)
Also this release contains some code that I've committed too, which is always a nice feeling :)