Most active commenters
  • kiririn(3)

←back to thread

Taylor Otwell: What 14 Years of Laravel Taught Me About Maintainability

(maintainable.fm)
105 points robbyrussell | 18 comments | 26 Aug 25 12:37 UTC | HN request time: 1.411s | source | bottom
1. kiririn ◴[30 Aug 25 12:19 UTC] No.45073990[source]▶
Still maintaining a Laravel 3 project. Barely made it 2 years before maintainability became a nightmare and the only upgrade path was complete rewrite. Projects written without an opinionated framework easily sail past 10 years of comfy maintainability
replies(5): >>45074063 #>>45074210 #>>45074585 #>>45075184 #>>45076069 #
2. dham ◴[30 Aug 25 12:31 UTC] No.45074063[source]▶
We started on Rails 3.2 and on Rails 8 now. Some upgrades were harder than others, but they never warranted anything close a rewrite.
replies(2): >>45074553 #>>45075064 #
3. conradfr ◴[30 Aug 25 12:52 UTC] No.45074210[source]▶
Apparently version 3 was released in 2012 though.

Is it even running on a still supported PHP version?

replies(1): >>45074468 #
4. kiririn ◴[30 Aug 25 13:25 UTC] No.45074468[source]▶
It's on PHP 7.4, so between RHEL and CloudLinux there's another few years left in it, before I weigh up rewrite vs another round of hacking modern PHP support into Laravel 3
5. kiririn ◴[30 Aug 25 13:34 UTC] No.45074553[source]▶
Not a Ruby/Rails person, but from a quick look there are still APIs named exactly the same between those versions. Very nice to see

On the other hand, Laravel decided to change from snake_case to CamelCase between versions 3 and 4, just because. Literally 0% compatibility

replies(1): >>45074772 #
6. ianhawes ◴[30 Aug 25 13:37 UTC] No.45074585[source]▶
Laravel 3 and Laravel 4 were released in ~2012. The upgrade from Laravel 4 to 5 (released Oct 2013) is probably the biggest hurdle, but you can likely upgrade from Laravel 5 to Laravel 12 in a week or sooner with Laravel Shift.
replies(1): >>45075045 #
7. gkedzierski ◴[30 Aug 25 14:01 UTC] No.45074772{3}[source]▶
They also completely changed the project structure recently, which made 100% of previous tutorials and examples on the internet obsolete.
replies(1): >>45075439 #
8. jt2190 ◴[30 Aug 25 14:37 UTC] No.45075045[source]▶
> The upgrade from Laravel 4 to 5 (released Oct 2013) is probably the biggest hurdle....

Can confirm. We started on Laravel 4 and it languished at that version until someone in leadership agreed to get it updated to version 8, which seemed to mostly be about some APIs changing. (The configuration system changed quite a bit for example.) Further upgrades from 8 to 10 then 11 have been very quick. (Note that we don't use Eloquent ORM so that wasn't part of these upgrades.)

replies(1): >>45075458 #
9. thibaut_barrere ◴[30 Aug 25 14:40 UTC] No.45075064[source]▶
Rails 2 to 3 was a bit more involved than others, also Ruby 1.8 to 1.9 !

But ultimately it got better IMO, indeed.

10. jt2190 ◴[30 Aug 25 14:54 UTC] No.45075184[source]▶
Laravel 3.2 was released in May 2012, so 13 years ago. Sounds like you should port the application off of Laravel since Laravel’s got an “evergreen”/regular updates maintenance model. I’m not even sure that 13 year old PHP is still maintained FWIW. I’m struggling to think of a programming community that tries to achieve a “we will maintain this for decades” approach, maybe another reader knows of something.
replies(3): >>45076410 #>>45077409 #>>45087689 #
11. kyleee ◴[30 Aug 25 15:26 UTC] No.45075439{4}[source]▶
Ouch, I haven’t kept up to date. Have any links explaining? Thanks
replies(1): >>45075749 #
12. richbradshaw ◴[30 Aug 25 15:27 UTC] No.45075458{3}[source]▶
We never did it - started but changes were too hard to manage on the large code base - we have L4 running on PHP 8.1/Mysql 8 and all is good currently!
13. gkedzierski ◴[30 Aug 25 16:06 UTC] No.45075749{5}[source]▶
https://laravel-news.com/laravel-11-directory-structure

Things which you were able to configure in the past, are now hidden. The meaning of many files (e.g. bootstrap) is now completely different. All different service provider classes are gone.

14. noir_lord ◴[30 Aug 25 16:51 UTC] No.45076069[source]▶
In Laravel's Defence (words I never though I'd say) the L3 -> L4 transistion was a nightmare because he went to PSR4/rewrote a bunch of stuff, I got bit by it as well.

All subsequent upgrades have been easier (if not always easy) by comparison - it was kind of a one time thing.

replies(1): >>45077536 #
15. toast0 ◴[30 Aug 25 17:25 UTC] No.45076410[source]▶
> I’m struggling to think of a programming community that tries to achieve a “we will maintain this for decades” approach, maybe another reader knows of something.

I just pulled a PHP site out of my archive that I had taken down 7 years ago. Only one function call (each) had been removed, and everything else still works. There's been some major changes in some parts of PHP though; if I had been following along, I'd have gotten a deprecation warning, but I jumped two or three major versions.

I'd be pretty confident in any Perl code written for 5.8 or newer to continue working, with CPAN libraries as well. Earlier code is probably ok as long as you don't deal with binary data or non-ascii characters; 5.8 was the unicode reckoning.

If you ran FreeBSD 4, most of FreeBSD 13 will feel familiar. Although if you had a kernel driver for FreeBSD 4, it will likely need a lot of help to work in FreeBSD 13.

Of course, there are other communities where everything is thrown away every 6 months. I don't have that kind of time.

16. loxs ◴[30 Aug 25 19:39 UTC] No.45077409[source]▶
I have a Rust web project written ~5 years ago. Zero updates until a month ago, also zero problems. A month ago I upgrade the docker file to latest rust, zero problems compiling. Could have left it to run like this for 5 more years probably but I decided to experiment...

I issue a `cargo update` to upgrade the leaf dependencies and do automatic minor version updates. Issue cargo check. Some new warnings from `clippy`, but it still compiles and runs without problems. Could have deployed for 5 more years, but I decided to experiment more...

I upgrade some of the libraries to major new versions - I am experienced and I know which ones will upgrade without problem. They do upgrade without problem. Could have deployed for 5 more years but decided to walk the extra mile...

I upgrade the more problematic ones, especially actix_web, the web framework, which had a massive rewrite and a huge new release with almost completely different API surface... It's a bit difficult to understand the changes, especially some parts of the old code written for the old version (which I no longer remember), but in an hour I'm done. Afterwards `cargo outdated` does not report any outdated libraries. I deploy for the next 5 years. Zero problems since then.

Well, it's not decades yet, but I can imagine similar effort to maintain it over the next decade.

17. Implicated ◴[30 Aug 25 19:57 UTC] No.45077536[source]▶
4.2 -> 5 is a problem. Pretty sure official docs recommend creating a new application and porting it rather than trying to perform a 4.2 -> 5 upgrade.
18. slifin ◴[31 Aug 25 22:31 UTC] No.45087689[source]▶
The Clojure community tries to achieve long lived applications

It helps that the core language has been incredibly stable