Long term support

[wotta]

Is laravel getting a long term support option for companies who want to use it ?

Since the way it is going now it makes no sense for a company to use it.
Can someone who actually has some decent info reply with useful info ?

[Garbee]

Since the way it is going now it makes no sense for a company to use it.

It makes a lot of sense for companies to use it. But it all comes down to whether the company wants to keep things updated or just set a project down and leave it for years without maintaining it.

This is largely a highly philosophical discussion that there isn't a right or wrong answer to. It all comes down to "it depends" based on the context of the project.

There is still a maintenance cost to LTS projects on the maintainers end. The smaller the team the harder LTS releases are in the long-run. Especially when things are going to break for someone while you're fixing someone else's bug. This has happened a few times in the current LTS and there is no good resolution when these things happen because someone will be unhappy.

[druu]

[wotta]

@Garbee I keep things small in a discussion so can you answer me the following.
Would you upgrade and edit your code where necessary every 6 months or would you rather have at least some decent backward compatibility ?

[sebastiandedeyne]

@concept-core I'd rather do incremental changes every 6-12 months than major changes every few years.

[wotta]

@sebastiandedeyne I am not talking about a few years. ( in my case at least )
But 6 months can be a pretty short term for a lot of companies.

For most of them, if they need to update the code once a year it is good enough.
But when they need to do it in 6-month terms it is too short.

You would get a situation where you are finished with the project but already spent for example 2 months.
That is what I am aiming for in this discussion.

Of course people will disagree with me which is fine but I would like to have a decent discussion about this.

[Garbee]

It's fine to do an annual update and knock two out at once. You don't need to immediately jump up to the very next version.

[sstutz]

it depends is always a good answer, but the question stands, does Laravel / Taylor plan on supporting LTS or not. I think a lot of people need to know this given it's implications.

Currently there is no official Roadmap, no one really knows what features will be added nor removed at each release cycle which makes it hard to plan ahead.

But it all comes down to whether the company wants to keep things updated or just set a project down and leave it for years without maintaining it

This is a bit too general. With the announcement of Laravel 5.5's requirement of php7 for instance, it not only forces a user to update the application but also the server infrastructure. Bigger companies do have security policies in place, they simply cannot update software and servers every 6 months. Not because they do not want to stay up-to-date but because they simply can't update everything hoping for the best.

Another Issue with this is compatibility of third party packages one may rely on, breaking API's during patch releases, no real upgrade guids / paths, etc.

Incremental changes are awesome, but things change rapidly, refactoring an entire application to use Laravel properly (as in refactoring old code to make use of new features, removing old broken dependencies in favour of laravel built in features) takes time, that every few months is not only a lot of work but also a lot of money.

So yeah, I guess a lot of LTS users and I would like to know what the deal is :)

[metasoftware]

From our side of things, some projects the lack of an LTS isn't an issue but for some of our bigger clients it most definitely is an issue.

I think without an LTS I'm probably going to end up using Symfony for some of those projects, as silly as it sounds their are contractual reasons on the client side (they request that things be based on an LTS rather than a point release, crazy but that is some clients).

[sede2]

Isn't 5.1 LTS?

[fernandobandeira]

Roadmap: https://laravel-news.com/laravel-release-process

5.5 will be a LTS according to that, since 5.1 will lose it's current LTS state, so you can see that you have one LTS now and seems that you'll have another one in the future...

[sstutz]

@fernandobandeira I am pretty sure this issue was opened because of this

https://twitter.com/taylorotwell/status/809768330118758400

[fernandobandeira]

@sstutz Didn't see that 😄

IMO it's not so bad actually, LTS just gives you a false sense of security, it's something pretty hard to maintain and it's not as stable as it sounds. it just makes you stick to a specific version of the framework, yes it's costly to migrate but it is needed.

5.1 branch has 2 commits per month meanwhile 5.3 gets 4x this daily, and that's because 5.1 is harder to maintain and don't get much attention, it's not because it's more stable, we don't create BC's because we want to, most of the time is the only way to fix a specific issue which we can't fix on 5.1 for example, there's many issues there that were fixed in 5.3 and we couldn't fix on 5.1 because it would introduce a BC...

So keep that in mind LTS is indeed an anti pattern and you can just stick with one version for one year, it will stop getting bug fixes after 6 months but will keep receiving security fixes for 1 year...

[michaeldyrynda]

This is a bit too general. With the announcement of Laravel 5.5's requirement of php7 for instance, it not only forces a user to update the application but also the server infrastructure.

This I can get behind. The organisation I work for has similar constraints in place, and even though we're using SCL on CentOS, we still have to wait for things to be updated in order to upgrade PHP versions. This doesn't keep us from staying on the release our platform supports, though.

Security fix backports are the reason why a lot of this infrastructure is still on PHP 5.3, even though it reached EOL nearly three years ago. I'm aware of some places still on 5.1.*.

Another Issue with this is compatibility of third party packages one may rely on, breaking API's during patch releases, no real upgrade guids / paths, etc.

That's what testing is for.

Incremental changes are awesome, but things change rapidly, refactoring an entire application to use Laravel properly (as in refactoring old code to make use of new features,...

Keeping your app up to date in an LTS would largely be due to keeping it current with security updates, not about taking advantage of new features. If you upgrade your LTS-based install for a security vulnerability, you're not going to get any new features anyway.

The support policy states that

For general releases, bug fixes are provided for 6 months and security fixes are provided for 1 year.

So you realistically get 1.5 years on any non-LTS release, which I think is reasonable both from a maintenance overhead (of the Laravel team) and somebody who has released something using it to update.

Most upgrades (depending on the size of the application) are fairly simple to upgrade and for everything else, there's Laravel Shift, which is a nominal amount of money to do most of the work for you - and certainly less than spending loads of time and money doing it manually. @jasonmccreary is biased on the matter - as the creator of Laravel Shift - but he makes good points about LTS being a trap.

...removing old broken dependencies in favour of Laravel built-in features) takes time, that every few months is not only a lot of work but also a lot of money.

Things like this don't happen terribly often, but again, testing will reveal those issues. Something like Laraver is handy for seeing exactly what has changed in any given released and a good test suite will give you assurances you're not going to have any issues.

I think for any application that you're actively developing i.e. your business' core application, it would serve you well to keep it up to date when it makes sense, but keeping up with patch releases in combination with a good test suite should be trivial. Whether you jump to the next minor release should be easier then.

Incrementally updating is going to be much less painful than waiting for an entire LTS cycle (up to 3 years) then trying to jump to the latest LTS - potentially six minor releases - is going to introduce to a whole world of pain.

I wouldn't hold my breath on seeing another LTS release, at least not with 5.5.

[joe-invita]

This http://symfony.com/doc/current/contributing/code/bc.html is ideally what laravel should be aiming for. I am currently working for a company that uses laravel. I feel that I am employed full time in rewriting projects. Our projects are sort of large, and the company hopes to have that project still bug free after 2 years since it cost it hundreds of thousands of dollars, and ironically a year and a half in development, just in time to be released as obsolete. And updating it every 6 month between minor releases is proving difficult when big concepts and functions just up and disappear or change fundamentally. Even if things go very smoothly(which it's really not) We can't upgrade and fully test the stability of a project before the next minor release rolls around and breaks it again.

In the previous company we used symfony, the code was more or less backwards compatible for 4 years(and still has 2 years ahead as 2.8 is backwards compatible and supported till November 2018), and with the newest symfony 3.0 the only thing that really broke was the form class, everything else remained functional, and that is in my opinion what enterprise needs. It took a couple of hours to upgrade several years old code to a new major release, in Laravel I am pulling my hair out to figure out all the changes between just 5.2 to 5.3 (the paginator accross the(huge) site broke, the services broke, the auth routes and concepts changed, and I am sure a bunch of things are waiting for me when I fix those)

[sisve]

An update: https://twitter.com/laravelphp/status/833710294446833664

Laravel 5.5 in July / August is scheduled to be our next LTS release.