When would you update the Laravel framework in a project?

If I have a good stable working version, probably only a known bug.

So, when using 5.1 that would be an update to whatever latest version 5.1.* is? That's what I was thinking about aswel, why bother to upgrade to a newer version if the functionality added by the update isn't used because the application is running correctly.

However, there must be people that update from 5.1 to 5.2 to 5.3, kind of curious to their thoughts and why one would do this.

Just came across Laravel Shift - this automates the update proces of the laravel core if I understand correctly and you can focus on updating the custom code (controllers, models, etc) yourself. Right?

If the app works no need to update unless it's a security issue which I don't think Laravel 4 or 5 has had yet.

Unless there is a reason like performance or to utilize a new Laravel feature for an update or even cause you want to. I still have clients with l3. Cost hasn't overcome the rewards.

@jekinney Dont you worry about future maintenance of the project? I'm working with an old CakePhp project that hasnt been updated to a new Cake version in four or five years and is becoming a massive headache. We're stuck on php 5.4 because thats as high as it will allow and at this point, updating to a new cake version would almost require a re-write. I feel that taking an hour or two to upgrade to a new Laravel version once or twice a year, plus taking a bit of time to update to newer php versions far outweighs the problems associated with having an application so far behind that it would require a couple weeks/months to upgrade. Also, upgrading is a good chance to refactor code and better organize.

I know I advocated Java technology sometimes because I came from java Technologies mainly servlets and JSP pages that was the one good thing about that technology longer backwards compatibility.

Don't get upset just conversating here, but just for a test I took some of my old code I had written over a decade ago tried it on the newer Technologies in other words the latest Java EE and it worked. I'm semi-retired now and don't have to worry about that.

But theoretically if I had to go back today and go back to using that dispatch software accounts payable accounts receivable the only tweak it would actually need is updated security. Maybe a few other little tweaks here and there but the point is it would still work. And if you read the java specs they do have longer backwards compatibility because once upon a time mainly large Enterprise would use Java Technologies.

Again please don't get mad that I talked about Java Technologies here just a comparison.

Currently rewriting an old Cake app as well. I kind of dreaded it at first, but once you revisit a years old project, you realize it only takes half the code to accomplish the same, if that ;)

That being said, I suppose an easy answer to this is, upgrade when you want to, or when you're paid to do so. Make sure your customer knows the downsides related to not upgrading, suggest an upgrade path or a service agreement which allows you to upgrade when you get the job. And make it clear to them that the cost of staying on top of the game might be lower than a complete rewrite 5 years down the road.

It would be nice if the maintainer of a framework would make it last longer for example what would have been the harm of Taylor tweaking laravel version 4.x to make it PHP 5.5 through PHP 7 compatible. Face it that would probably have been very easy for him to do with his expertise whereas end uses of the framework most of us probably don't know how to do that. Some probably do.

My biggest issue is what @zachleigh said: future maintenance and being able to spread the work for updating the project over multiple months/years instead of having to rewrite a large piece of your software 3 years further down the road.

The projects I started in 5.1.x all make use of an external permission/roles package, while 5.2 comes with it's own, I'm kind of curious to see how much work it takes to update to L5.2 or even L5.3 in a few days/weeks when it's released. Laravel Shift seemed like a good starting place, it automatically updates the framework code and creates a seperate Git branch. I think I'm going to test the effort it takes to update the code in a few weeks after the storm settles (the storm being clients that are pushing ;)) just to get some experience in it.

I even have had procedural PHP projects from 5/6 years ago that I'd wish I had updated at least a little bit to the most recent changes of their CMS basis that I'm using in projects I started later on. Old code is a bitch.. definitly if you get used to the newer code.

From my own, very limited experience: the longer you leave it, the harder it gets.

I've been told that the Guardian newspaper web team is considering using the age of code as their main quality measure: take a class, and average the age of every line of code. Older = worse. I thought that was pretty interesting.

Maybe this doesn't apply for some projects. Old isn't necessarily bad. But often code gets old because it's hard to change -- or risky, or expensive; and I think that is a sign of unhealthy code.

However, I would never update to a brand-new Laravel release -- unless there is a new feature I'm desperate to use. I like to wait a few months at least, so that all the little undocumented issues can be discovered by the community, and the tutorials have started to move on to the current version.

So my preference is "reasonably current, but not cutting edge".

As for handling the update? I think it helps a lot if you have confidence in your test suite. Ideally you want to feel like, "the tests show green, therefore nothing has broken". Beyond that, it's just a matter of following the upgrade guide in the docs, and also reading about what other people seem to be doing.

Sometimes with Laravel there are undocumented breaking changes. There was one in 5.2 -- Taylor just flat-out removed $this->dispatchFrom(). That's another reason for waiting a little, so the community can find these things.

@Pendo I only update a Laravel version if I know I have the time to perform the update and any issues that may crop up between the two versions, or if I really need a feature in a newer release.

As mentioned cost to upgrade is a huge factor. Look at the repo patterns big argument for easily swapping db. We all know swapping from a rational database to a document type is very time consuming mainly to transfer old data to supported new data. 99% as a freelancer your clients will see no benefit once they know the cost :).

Same as upgrading. Clients care if it works period. How it works and why not so much.

Working in a company maintaining an in house app, different story. Even a company with large accounts.

Right, I guess I'm on the same page as most of you. For my own CMS I would maintain and update the source better en quicker because it's going to be used on multiple projects. Custom projects like the ones I mentioned need to work. Too bad I'm just starting to get into TDD (or at least into writing tests), so for the past few projects it will be a lot harder to test and check all code after an update.

Laravel 5.1.* will be good enough for the near future anyway.. based on the opinions/experiences you guys have I don't think I should think about it too much. Thanks all :)

I have upgraded projects from l4 to l5 because its a major change and some clients still running l4 happily.

usually i get tempted and move personal project to latest version but honestly i don't see any benefit.

if i want to utilize a new feature, again its extra work (assuming your old code is working properly already)

so currently my strategy is sticking to LTS (everywhere not just with laravel but also with system OS) if a new LTS version comes and your app still used by people then go for it.

if its a client project, upgrade as many times as client wants :D

NIce discussion.

A bit late to the party, I have a production application on Laravel 5.4 and latest is 5.6 (at the time of writing this). I am not upgrading yet.

I'm also late to this party! I'm a business owner/manager, but a developer myself many moons ago.

Our agency primarily supports Drupal and WordPress, and the Laravel framework. We have fee-based maintenance contracts with most of our clients with Drupal and WordPress sites so that we are responsible for keeping them updated to the latest versions.

In the last couple of years that we've been working with Laravel, we've taken somewhat of any ad-hoc approach to updating Laravel applications, i.e. definitely not the well-defined, semi-automated workflow that we have for Drupal and WordPress sites.

And now I'm definitely in the mood to formalise our agency offering in this regard, both as a way of increasing recurring revenues streams, and of providing a genuine value-add business service.

So like @pendo , I'm snooping around looking to better understand the business case that I need to put together to offer up such a maintenance contract to our Laravel clients.

And like @pendo, I've also Googled and found the Laravelshift.com service, which (first glance) appears to make the process more reliable, etc.

So I'd be very interested to hear feedback from others on this topic, especially anything that will help me to:

• Make a solid business case to clients as to why it's important.

• Learn what experiences others have had, good or bad, of using Laravel Shift to help smooth the process. We currently use and love Envoyer. I'm not sure to what extent Laravel Shift with partially of fully replace Envoyer?

• And general do's, don'ts, etc.

Thanks :-)

I'll jump in here as the creator of Laravel Shift to focus on answering @itomic.

make a solid business case

As much as we want to believe "security" is enough of a case, the reality is it's not. Clients really only become convinced of this if they have experienced a hack first-hand. Otherwise, it unfortunately falls on deaf ears. For completeness though, I will note anything below Laravel 5.5 is outdated and vulnerable. And with the exception of 5.5 (LTS) and 5.8 no versions receive bug fixes. Source

I think the only selling point is efficiency. Said another way, to charge clients more to work on older apps. This is not an uncommon practice, but unfortunately not universally shared. Which creates a competitive risk. Nonetheless, this "legacy tax" is the only way to push a client towards staying up-to-date as it will save them money. If they still don't, well, you're then making more money.

The other side of that coin is the promise you can develop features more efficiently. This is naturally true assuming your agency is used to working on the latest Laravel version than older ones. Not to mention the latest version of the framework provides more out of the box, as well as more package support.

Simply look at a feature like new user email verification. It's built into Laravel 5.7. But if you're running an older version, you have to built it or find a package. Same with backend administration tools. Pre-Laravel 5.7 you'd have to build it or use a package. If the client were up to date, you could drop in Nova.

Shift vs Envoyer Shift is an upgrade service. It provides automated and human services to upgrade older Laravel applications to the latest version.

Envoyer is a deployment service. It provides zero-downtime deployments of your application. Although it may "update" your application in a production environment, it does not "upgrade" your application code in any way.

So while you may use both for your Laravel application, they serve very different purposes.

do's and don'ts

• Do upgrade your application.
• Do pass-thru the cost to your client
• Don't let an application sit on older versions (including LTS)
• Don't just run composer update for new versions, you're just deferring the technical debt.

For completeness though, I will note anything below Laravel 5.5 is outdated and vulnerable. And with the exception of 5.5 (LTS) and 5.8 no versions receive bug fixes. Source

Glad someone pointed this out by the time I read all the way to the end :)