We notice some bugs are being ignored while lots of intents/changes that are just introducing extra layers of execution without other benefits get attention

[macropay-solutions]

Laravel is named by many a new PHP language.

If you start learning PHP by using laravel you are in deep shit.

You will learn N layers of functions that behind the scenes will use native php functions but, to get to those, you will have to dig deep into the framework.

Many merge requests want to or already introduced things like:

->when($condition, $callback)

->finally(...

and we could go on for minutes but, we won't do that here.

The point is, all these are is just USELESS overhead from the performance and logic points of views.

People are used to not write code anymore, they expect the framework to write it for them. There will come a day when AI will do that and they will stop earning...

A side effect of this habit is that you need to learn the framework's code to know exactly what is does when using these nested extra layers just because you want your php files to contain as less text as possible.

But, only few can learn it or want to learn it. This can be seen by the number of non issues created as issues despite all laravel code is written in php not in another language.

In contrast to this, old issues that are considered corner cases are NOT FIXED...
Also, these new "aspect" changes are introducing new bugs and sometimes even breaking changes.

We had to fix numerous old bugs (not fixed to this day in laravel) by using macros, callback bindings, overwrite the Eloquent and Query Builders, Relations, Model etc. and when breaking changes to the functions' definition happen in these overwritten classes, then we need to adapt to the latest changes and that is not so easy when we want to keep compatibility to laravel >=8.

You would ask yourself "Why keep compatibility to a version that is not supported anymore?".
Answer is: Because [old] bugs are FEWER than [old - old_fixed + new] bugs.

[Sophist-UK]

The issue created by maintaining Backwards Compatibility

This is a fairly typical consequence of preserving backwards compatibility.

1. You start with a beautiful clean architecture.
2. You fix things by bolting stuff on the outside rather than by rearchitecting because you don't want to create backwards incompatibilities.
3. The things you previously bolted onto the outside later get things bolted onto them.
4. Sooner or later you have (to a greater or lesser extent) an ugly monstrosity.

And THAT is why major versions exist - so that you can remove the bolt-ons and fit them nicely into the architecture giving it newly clean lines.

Of course this means developers having to recode, so as your user base grows you become more and more reluctant to clean up the architecture when you have a major release (and it also becomes harder and harder to do so as the code base grows because of the amount of framework code you need to change and test).

However, neither of these is an excuse in itself. Refactoring tools now exist to help developers to make the code changes to switch to a higher version, and sometimes you need to break things to clean up the architecture in the long-term longevity interests of the framework.

This decision making is also made more difficult by an increasing level of commercialism which can (if you are not careful) introduce a bias or conflict of interests on whether or not to make these breaking architectural changes in major versions.

Now, I am NOT saying that this is actually the case with Laravel here - I am simply not knowledgeable enough at the level of detail needed to make ANY judgement about this - my comments above are generic.

What I will say is that being the leader of this type of framework project is IMO a VERY difficult juggling/balancing act choosing between keeping the architecture clean and not creating too much grief for developers when you deliberately break things with a major version change. None of us have either the depth of insight or the responsibility for making these choices - that person is @taylorotwell - and I think I do know enough about these difficulties NOT to second guess him.

What I will say is this... whilst we may all rile a little about Taylor's reluctance to accept PRs, when it comes to trying to preserve a clean architecture, rejecting community PRs is almost certainly the first line of defence.

But I do worry a little when some of the pre-announcements for v12 stress that one of the major bullet points is the high level of backwards compatibility. However I do remember how major the breaking the changes were to get us from PHP 4 to PHP 8 and that the community both coped with these changes and ultimately benefited from them (Laravel and its ecosystem would probably not be possible in PHP 4), and I would encourage @taylorotwell to be more bullish about breaking changes in new major Laravel versions if needed in order to keep the architecture clean.

[shaedrich]

And THAT is why major versions exist - so that you can remove the bolt-ons and fit them nicely into the architecture giving it newly clean lines. […] the responsibility for making these choices - that person is @taylorotwell […] I would encourage @taylorotwell to be more bullish about breaking changes in new major Laravel versions if needed in order to keep the architecture clean.

I said it in the past and I gonna say it again: A huge problem I see, is communication. There's no clear roadmap as to what we intend to sunset in the next major version or the major version after it. I'm also in favor of closing PRs that might not be a good idea, however, I've always pointed out the lack of clear communication as to why they are closed and will continue to do so. This poor communication also leads to PRs being submitted multiple times in a row, be it by the same or different devs, because nobody can say for certain if the original PR has been closed because of a typo or a conceptual flaw.

[Sophist-UK]

Yes - I agree fully that the communications from the Laravel team could be better, and here's my shopping list here:

• Clear guidelines for how the community should approach bug-fixes or enhancements - discussions, Issues, PRs, independent packages - and some guidelines to suggest which types of PRs are likely to be accepted / rejected.

• Perhaps a more formal means of submitting ideas for PRs to get Taylor's viewpoint before putting the effort into developing one, so that you can have a better idea of whether your efforts will be worthwhile or wasted.

• As you suggest, better descriptions (even if boiler plate text from a range of prepared explanations) as to why a PR is rejected. I suspect that mostly Taylor believes that either they are not core functionality (and would grow the code base without sufficient benefit), or would create backwards compatibility issues, but it could be that he has architectural concerns, or even simply that he doesn't personally like the new functionality.

• A general roadmap for future major versions - especially as you suggest a clearer indication of what will be sunsetted and why. Leaving the communications aside, thinking ahead about e.g. what will be sunsetted in V13, would allow deprecation log messages or PHP notices to be issued in development but not production environments to give advanced warnings of future sunsetting.

Leaving aside the uncertainty caused by poor communications, IMO these would also lead to greater transparency and remove even the slightest suggestion of e.g. commercial conflicts of interest or favouritism whereby PRs from well known community members get approved whilst the same PR from someone unknown would get rejected.

[Sophist-UK]

Laravel as a new language

I am not sure I have enough knowledge to be able to comment on the pros and cons of using closures or callables in the way @macropay-solutions is calling out here.

But, my belief is that Laravel has never attempted to try to avoid the need for its users to know PHP.

I think that the objectives of a framework are (in priority order):

1. Avoid reinvention - and this speed delivery times, avoid bugs.
2. Standardise code so that it is more readable and maintainable.
3. Be a foundation for innovation on top - and boy have we benefitted from a lot of that.

Nowhere in this list is the idea that Laravel is a language in itself, and that you don't need to understand PHP.

And whatever building blocks Laravel provides to avoid you having to code (or miscode and debug) the same old functionality - and what a broad set of building blocks it is - whilst you can often just butt these building blocks together (which is in itself a testament to how great it is) sometimes you still need to bridge between these building blocks with bespoke code.

Furthermore, as I am sure @macropay-solutions would agree, the documentation level of Laravel is really only a starter, and that you frequently need to read the code to understand how to use that functionality to its fullest - certainly I find myself doing that quite a lot. Fortunately Laravel is open source - however imagine if you didn't have access to the source code, and the version you downloaded had been obfuscated. Just how difficult would it be to use Laravel then? The point of this is that if you need to read the code, then you need to know PHP to be able to do so. Of course, the knowledge you need to read and understand PHP is a lot less than knowing enough to be able to write it.

[macropay-solutions]

An official package with traits and helpers that would incorporate all the overhead would be pure GOLD. In that way only who wants overhead can use it.

Also if the team does not want to fix bugs (example #51825) in the core because of backwards compatibility issues, those bugs could be fixed via a lib also.