First off: I am absolutely a big Laravel fan and appreciate all the great OSS stuff the Laravel team is doing :heart:
Also, I am not trying to pinpoint anyone in the Laravel team because I think they're just acting on the practice that has been set. This is not a personal attack on anyone.
I think there is a tendency of closing issues really fast. Here are the two types of issues that are currently getting closed but should not be closed in my humble opinion:
Issues that are confirmed bugs but the Laravel team doesn't see it as a major issue or don't have the time to work on it. An example is https://github.com/laravel/horizon/issues/712. This was a confirmed bug (excerpt from the issue: the comment inside config/horizon.php is for memory_limit wrong) which was closed. I understand if the Laravel team doesn't want to work on it but issues like this should remain open imo (should allow to be surfaced) so that the community members can help out in resolving them!
Issues that are reported for an older version but may persist in a newer one. I think the current mandate is that close all issues that don't pertain to a supported version. That is fine but my recommendation is that unless the Laravel team or someone from the community or the OP confirms that the issue doesn't persist to a supported version, it should not be closed. Example: https://github.com/laravel/horizon/issues/906 and https://github.com/laravel/horizon/issues/845
I think the first type of issue should definitely not be closed and the second type is more of a problem for Laravel first party packages. For first party packages like Horizon, only the latest release receives bug fixes. So, there are much fewer people running these packages in a production environment on the latest version, and type 2 issues are closed / missed / not investigated properly.
Just my 2 cents. I absolutely adore the Laravel team on launching so many new and super useful packages such as Jetstream, Sanctum, Fortify, etc. over the last few months! Please take this on a positive note. Thanks!
Thanks for the feedback 馃憤
/cc @driesvints
Hey @paras-malhotra, thanks for posting this. Definitely great to see you liking Laravel, thanks!
I realize that it might come across as we're closing issues fast but I'm happy to explain to you how we work and why we can't provide personal support for every single issue. First of all, we receive dozens of issues on a daily basis across over 25 open source repositories. It's almost a daytime job at replying to all of those and fixing the reported bugs.
Let me reply to your two specific points:
This issue was open for a long time. It wasn't entirely deemed a bug by us so we marked it as an enhancement issue. As this wasn't something we were going to work on ourselves we left some time for someone to pick it up and send in a PR. The issue was reported on November the 28th 2019 and I closed it on August the 8th 2020. In between that nobody attempted a PR. Because of that we closed it because we don't want to let issues pile up to keep things manageable for ourselves. If the issue was so important to be fixed for others I'm sure someone would have sent in a PR.
It is unfeasible for us to attempt to recreate every posted bug report for unmaintained versions of our first party libraries. We have a support policy in place exactly for this reason to prevent the workload for ourselves. We get issues like this so regularly that we'd be investing so much more time into recreating issues instead of focusing on other things like improving the libraries and creating new software. We indicate this clearly in our support policy and on our issue templates right before you open a bug report. Some people miss this which is why I often post a saved reply asking them to attempt to recreate the bug report in the latest version. It's also not always easy to recreate an issue under the exactly and much older versions an OP is posting it. Other library maintainers are moving on as well and dropping support for third party dependencies as well because they, just like us, cannot keep on supporting older versions.
All in all it boils down that we cannot provide support for every older version out there. One other thing we attempt to do with our stricter versioning policy is to push people to upgrade to newer versions sooner rather than later. If you're staying on older versions you'll make it that much harder to move on to a new one later on when the incremental version jump will be that much higher. In general we try to keep upgrades as simple as possible between the framework and the first party libraries.
I hope that answers your post a bit. In general I want to say that I appreciate you bringing this up for discussion, thank you for that.
@driesvints thanks so much for your response. I'm very happy that you and Taylor have taken this as positive feedback rather than criticism.
I can only imagine how difficult it must be to manage 25 repositories on a daily basis! Thanks again for your response 馃憤
Most helpful comment
@driesvints thanks so much for your response. I'm very happy that you and Taylor have taken this as positive feedback rather than criticism.
I can only imagine how difficult it must be to manage 25 repositories on a daily basis! Thanks again for your response 馃憤