LTS or latest version - which should be used?

LTS is a joke, really. It's an "enterprise" requirement for some poor shlubs. "We want you to promise you'll support the software for x years or we're not using it!"

Who knows what the future holds? We chose Laravel because we wanted to be on the leading edge of what is being done in PHP and we want both our team and customers to be able to reap the benefits of using the most advanced technologies available to us. The sacrifice we make is investing time it moving from version to version and with each minor release there is definitely some modicum of pain to be had. Another way to look at it might be to imagine your are on 5.1 now. Read the upgrade guides for 5.1 -> 5.2 -> 5.3 then think about what happens when LTS ends and you want to move to the next LTS version (say 6.1). Now that right there will be PAINFUL. My advice? Go with the latest and take your medicine each time a new release is available.

@lindstrom Thanks for the response.

So what you are suggesting is that start with the current latest and upgrade (probably every six months) whenever a new release is available.

Yeah I think it takes the whole LTS thing out of the equation.

I originally stayed with 5.1 ... lots of pain to move up to 5.3. Also, you need to consider packages that you are using. On top of the idea if the latest versions of laravel provide enough reason to update. 5.1 to 5.3 is pretty convincing.

One issue I have with laravel recently is that lots of directory changes are being made ... now having routes as "first class" citizens is almost the very same reason why they were supposed to be in the Http directory. ugh...

5 years support for laravel should be rather easy if you look at the longevity of Code Ignitor. The big problem is that over the coming 5 years, laravel could morph into something that none of us expected. Just take a look at how different 3.x and 5.x are!

@andy Thanks for the inputs.

"The big problem is that over the coming 5 years, laravel could morph into something that none of us expected. Just take a look at how different 3.x and 5.x are!"

That's exactly why I think upgrading with every new release as suggested by @lindstrom after starting with the current latest would make much sense.

Awaiting for some more views, would be awesome if guru Jeffery Way could provide his opinion.

I think it ultimately depends on the project. The larger it is, the more difficult it will be to update whether that's from one version to the next or from one LTS to the next. More often than not, the reality -- I think -- is that if it's not broken, there's probably not a need to upgrade.

Yes, I'm suggesting exactly that. However, @andy has a great point about packages. I would heed the advice of not going package crazy and to be very selective of the packages you do include. Looking at my composer.json (at work, a real app serving thousands of customers), the only thing that would cause grief would be maatwebsite/excel. Keep it lean and mean.

There's been some suggestion that there might not be another LTS. See this for instance.

I like LTS stuff (OS's, libraries etc) as I've got a very large amount of code and servers to look after with a team of, urm, just me - upgrading them is really very time consuming. I'd be quite happy with an LTS release which was 'security updates only' for a few years - no other backports, changes or anything. That way at least I can plan a rolling update across the code bases. But we'll see...

For some reason, I want to work with the latest version of any package / framework / whatever I use. I feel bad when I see some cool feature in a newer version that I could use to make the app better or amazing but I don't have it.

@lindstrom First of all C.H. Robinson paid over 23 million for there worldwide logistics software, you can bet they need the joke (long term support). @Ruffles if 8 months ago you paid 23 million for software, and a new cool feature is out, you'd drop it and shell out another 23 million. Folks get real, large enterprise isn't going to mess with laravel or active record. Perfect for medium to small companies. I doubt fedex, ups, or JB Hunt, Landstar, etc would even consider php. Most use Java technologies for their heavy hitting database work. Not to say a customer frontend could be php.

Sorry @jlrdw but you're incorrect. Certainly not in every case but there are a large number of large enterprises using PHP based apps.

Pfizer, for example, is a huge multi-national enterprise ... using Drupal.

@willvincent Maybe for public, heavier stuff, asp.net view-source:https://globaljobs.pfizer.com/pages/jobs.aspx

Looks like they use many, partial job description

general knowledge of computer programming languages, such as LabWare LIMS Basic, C++, Java, .NET, SAS, PHP,

Edit: I am not saying laravel is bad, I love laravel and how flexible it is, but for true long term support, the one thing that hasn't changed too much is PDO. So if code is written to a standard it's a breeze to even change frameworks if necessary. But really your c++ Java languages are better suited for coding something that has to be around a while. Really LTS in a framework, don't count on, frameworks come and go, and change too much. Bank on the language.

Really LTS in a framework, don't count on, frameworks come and go, and change too much. Bank on the language.

Ultimately I agree.. to a point. Of course if the language is abandonded, or breaks.. you banked on the wrong thing :)

Anyway, there's no reason that one can't remain on version X.Y pretty much indefinitely.. any .Z updates will be unbreaking changes, that's kind of the point of semantic versioning. If X or Y change, expect something to break, if Z changes, no big deal... and nothing is preventing anyone from backporting some 'cool new thing' they just have to have from a newer version of the framework, as a separate package, for instance.

After all, it is all the same language, so with a little effort, those cool new things can (almost always) be backported with fairly minimal effort.

Id like to add my two cents, I agree with @willvincent above.

if the company you work with wants an LTS release you are all good. You don't need the newest whatever.

lets get some perspective, There are hundreds of rails 2.3 apps in production I believe hulu.com is still one of them or was for many years. (I used rails 2.3 something like a decade ago or close to it.)

You are going to build an app now, with libraries and composer packages that exist now. The constant upgrade track has you constantly upgrading all of your composer stuff as well as your npm dependencies. What if the packages you added in npm or composer go unmaintened and don't work with the newest versions of laravel or the newest version of php laravel forced on you? Now you have to fix those packages yourself and maintain them yourself or write new ones and maintain those.

As far as PHP not making it into the enterprise, I don't buy it. I have worked in too many enterprise environments, feature set and cost are king. The top three most deployed voice switch management apps are all written in PHP. I'm not saying there are not a lot of bigots in the enterprise space but it's loosening up.

fwiw taylor has said in a recent laravel podcast that he is finally happy with the directory structure as of 5.3 (im not sure how much to trust this) but you might try a hybrid. Hop on 5.3, since 5.1 is getting a little long in the tooth and you can take advantage of php7 and migrate until you hit the next lts and freeze your libs and codebase at that point.

Don't get me wrong there are positives and negatives to both sides and im addressing the pro LTS perspective because I feel the other side of the equation is represented well here already. It has lots of pro's but its far from perfect of pain free, and you could do a lot worse than picking a codebase and libs that work right here and now, get more familiar with it over 5 years so that you and your team can take over security fixes afterward. Whatever you choose, try not to sweat it, seriously you are going to make a million decisions and this isn't a super big one. you will probably be happy either way

P.S. one downside of LTS that I have not seen mentioned is if you are newer and watch a lot of laracasts to help you learn to implement functionality you will notice there is not really any LTS 5.1 related content here. New series always come out on the newest release at the time. Im not sure if @JeffreyWay intends on adding more content on LTS stuff, but since the newer fun stuff to cover will always be newer I wouldn't bet on seeing a lot of LTS related content

@ohffs wow thanks I had no idea about this: https://github.com/laravel/docs/pull/2506

Kind of completely takes the wind out of the sails if you don't know what to bank on.

I still think even if the term "LTS" isn't used there is something to be said about deciding if you want to upgrade or freeze your app and libs once your app is built. Rails 2.3 wasn't an lts release but there is still a lot of it floating around.

New series always come out on the newest release at the time. Im not sure if @JeffreyWay intends on adding more content on LTS stuff, but since the newer fun stuff to cover will always be newer I wouldn't bet on seeing a lot of LTS related content

I'd guess probably not as well, but not just for the sake of newer stuff being newer, but because 90%+ of the old stuff still applies. Sure some of the older hands-on series are outdated, but so little has really changed that most of it can be slightly reworked to use in 5.3.

As far as I know, if a company needs to choose a technology that would help them with millions or billions of records / users / features, they would probably choose a Service Oriented Architecture over a single framework / language. I mean, they might start with a framework or two but then it will build up into a huge giant.

Every language has its own ups and downs but when you combine multiple of them in a huge project, they will perform better than you might expect. That's probably the best way to gain performance in every part of your project.

Also, don't forget that big companies most likely have experienced people who can build their own stuff for the project and the framework they started with, might not even be recognized later on after years of work.

@Ruffles I agree most of these companies are so huge they leverage almost all internet technologies. Even The State of Texas, what the employee sees vs what the public sees on a website is drastically different. For public viewing site is made more "pretty" so to speak.

latest version,

for example: laravel 5.3 change DB:: result to a object, but 5.1 is an array, if your project is too bigger to update,.

I am truly overwhelmed with the responses with so many different perspectives, a big THANK YOU to everyone.

I had posted the same question on SO and to my utter surprise, apart from one upvote for the question, it got 3 votes for closure. Even after I humbly asked for the problem with the question to help me understand the reason for "votes for closure" I didn't get any response.

@JeffWay thanks for providing this forum - a medium for Laravel users to get help from gurus.

I sincerely appreciate each and everyone here at Laracasts for their responses.

@jlrdw I agree with you that very large enterprises may have their own skilled people in house and may be inclined towards technologies based on Java or C /C++ etc.

While the new generation small and medium enterprises are the ones which are the target segment for small time developers like me. And in my experience, these SMEs are very focused on their core activities and want to outsource the IT part, however they are not unaware of the pitfalls and do ask about security updates and how long will we support the app for security updates or vulnerabilities which may be discovered in future.

As far as enterprises (read medium and small enterprises) not preferring php, I agree that most prefer Java or c/C++ as they may have heard that all big enterprises prefer these technologies for stability and various other reasons. But I tend to convince them with the argument that Facebook, was built on PHP and they do have security in place for millions of users and their contents.

So they are not averse to PHP any more, since they are also not keen to invest on resources required for maintaining Java hosting. They are still inclined towards ASP.NET where they have in-house System Admins for the Windows stack. However in such cases as @getstratify suggests, with the latest Laravel and PHP 7 we can highlight the performance boost with PHP 7

@willvincent I agree that we should follow that "if its not broken do not change (upgrade)". As is its a pain to upgrade any sizeable app to any new version of framework.

But if there's a upfront commitment for security fixes for 5 years, I feel that planning to upgrade with every new release will provide a way to do the upgrades in a planned way with minimal downtime as against a case where I stayed with an LTS release and suddenly the need arises to upgrade to the latest version (maybe 4th or 5th iteration over the LTS) due to a newly discovered security threat. It would not only be more painful but could seriously affect the downtime as well putting at stake the developer's reputation with the client.

@getstartify suggestion of keeping external packages to minimum is a great one and definitely one to be careful about.

My purpose of asking this question is that

LTS versions support security fixes till 3 years while non-LTS versions support till 1 year

How to handle 5 years support commitment as a developer?

One possible way I can think of after @lintstorm inputs is that upgrade with every new release till at least 4 years so that I am covered for 5 years for security fixes.

Please excuse me if I may sound stupid, but I would really appreciate suggestion for the best approach to supporting 5 years of security upgrades (as a commitment) for a Laravel App.

@willvincent

Anyway, there's no reason that one can't remain on version X.Y pretty much indefinitely.. any .Z updates will be unbreaking changes, that's kind of the point of semantic versioning.

Taylor has explicitly said that laravel doesn't follow semantic versioning - so there isn't any guarantee that a .z change won't break things. See the 'web' middleware changes during 5.2 for instance. It's one of the main things that makes me wary of the framework - much though I love working with it. The nagging feeling that 5.3.x code won't work the same on a 5.3.y and then change again on 5.3.z :-/

I got an interesting comment in response to my (same) question on SO

"Don't develop for Laravel. Simply break your project down to libraries that you can handle via composer. Use Laravel to glue libraries together into a web app. Use Laravel's helper classes (you can define them as dependencies for your composer project) - that way you can have version constraints and upgrade version as required. How's that? "

"Simply break your project down to libraries that you can handle via composer" - Means to break various functional domain into separate custom package which could be pulled in through composer.

"Use Laravel's helper classes (you can define them as dependencies for your composer project) - Means to define Laravel's helper classes as dependencies (composer dependencies) in composer json for the custom package/or the main project.

"Use Laravel to glue libraries together into a web app" - couldn't understand this part

"that way you can have version constraints and upgrade version as required" - couldn't understand this part either

I got more input from the solution provider - the solution could be :

Use Laravel for routing requests to Controller and mapping Models with all goodies of Middleware, Policies etc.

Encapsulate all business logic in custom packages - doing it this way the process of upgrading becomes less painful if the custom-packages are designed carefully not to be tightly coupled with specific release.

LTS versions support security fixes till 3 years while non-LTS versions support till 1 year

How to handle 5 years support commitment as a developer?

@neeravp, the short answer is that no one is going to guarantee that for you: you will have to do it yourself.

Not many products / libraries / frameworks would guarantee that they are going to be supported for 5 years. And when they do, it's usually because you paid a good sum of money for it.

What I mean by "you have to do it yourself" is that you will have to plan how you are going to fulfill that commitment with your customer. There could be different options. For instance:

• You stick to framework version X, making minimal or no changes to your codebase. When the official framework support ends, you take over and "take ownership", fixing whatever security problems there may arise.
• You keep evolving your codebase on a regular basis to be able to use the latest supported framework.
• If you foresee that the customer will want to introduce new features in the product, you can stay with framework X until a new feature is requested and then update to the latest version as part of your develoment cycle.

But whatever approach you take, you have to account for some level of effort (ie. money in your proposal) and you will have to take a level of risk, as I bet you you won't be able to predict where this industry will be in 5 years! :-)

And having said that, if you use any JS in your application, Laravel could be the least of your problems...

@otepas

if you use any JS in your application, Laravel could be the least of your problems...

Reminds me that I saw this news about vue-resource this morning.

@otepas Thanks for your inputs.

I am making up my mind to take the following approach

1. Isolate all business logic into custom packages - separated based on functional unit or domain entity

2. Keep the dependency and usage of external packages to minimum.

3. Keep the custom-packages fairly independent of any particular release version and/or external package - to the extent possible.

4. Start with the latest stable release currently available.

5. Account for regular upgrades (every six months in tune with the current Laravel release cycle) and have a plan in place for upgrades.

6. Upgrade with every new stable release.

You are spot on with "if you use any JS in your application, Laravel could be the least of your problems.."

I guess a similar approach for JS would be to

1. Isolate the app specific view/business logic in custom components.

2. I am comfortable with and use Vue.js for my projects so keep the custom components fairly independent of release specific features For eg: I don't use Vuex for state management - rather prefer to implement state via a Plain JSON object and combine with event bus on separate Vue instance to manage state for the application - in future am planning to develop custom event bus in plain ES2015

3. Keep the dependency/usage of plugins at minimum - use plain ES2015 as far as possible, although it requires more efforts and probably reinventing the wheel sometimes.

4. Stay with the latest stable release - upgrade as necessary.

I don't know if above would be a good approach for the JS part - but this is what I have in mind as of now.

Had requested @TaylorOtwell and @JeffWay via twitter to have a look on this thread and provide their valuable input .

The reply from Creator of Laravel - Taylor Otwell is "latest" (tweet reply).

I am obliged that he really took time to consider my request and then responded as well. Thank you @TaylorOtwell .

His reply kind of encourages me to keep up with the latest stable release.

@ohffs - I don't hang on Taylor's every word like a starry eyed schoolgirl, so.. thanks for the heads up, I had no idea. Guess I've blocked out the middleware stuff.. though it sounds vaguely familiar. :)

I take back everything I said about versioning, if semantic versioning is not in play here none of my prior comments apply. Hopefully that is something that Taylor reconsiders though as it's really not ideal to have breaking changes in point releases with the same minor version, and that will certainly prevent adoption of the framework in a lot of cases that it otherwise needn't.

but I would really appreciate suggestion for the best approach to supporting 5 years of security upgrades (as a commitment) for a Laravel App

First stay up to date on the what's happening with latest releases of laravel, if an update was a security patch, that sort of thing. And stay on top of the php version used, they also have security patches, etc. It does take a little homework to stay on top of security, when doing things in house.

And just for you general info, Facebook yes uses php, but some heavy hitting code are compiled c++ classes.

@willvincent I only found out by accident when I asked about something else - I'd assumed it was semver up until a few months ago too :-/ As far as I can make out there's zero documentation (other than anecdotal/twitter/whatever) about what the versioning policy actually might be :-/ I think there was some discussion about adopting semver at the 5.0 release, but nothing came of it.

@jlrdw Thanks for the pointers.

"And just for you general info, Facebook yes uses php, but some heavy hitting code are compiled c++ classes."

Nearly all huge projects like Facebook and likes use some tech based on C/C++ or Java in their mix. When and how is the decision to use such tech taken? What I mean to ask is how the decision is made that probably PHP would not be ideal for a particular requirement and that compiled language is required to be thrown in the mix for reasons may be related to performance or security? Are there any thumb rules governing such decisions? For example if the app would have more than 10000 concurent users then go in for a compiled language processing class or something like that?

Started out with Java Technologies never used compile C++ but this is information that I have read from other sourses. And admittedly at the trucking company I worked for it was intranet not internet. But from what I have read it does have a lot to do with thousands of hits vs just a few hits on a smaller site. But by no means am I ready to program something as large as a FedEx site. You right a lot of large companies have proprietary techniques they have come up with. Irregardless good luck along your path and Godspeed.