This repository was archived by the owner on Mar 14, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Mar 14, 2024. It is now read-only.
Figure out the best deprecation pattern for Laravel 8.0 #217
Description
Taylor's opened a PR to extract Collections from Support (🥳), so Collect won't be needed.
The simplest thing we could do is to just stop releasing after 8.0.
But I'm curious whether package authors who rely on Collect would prefer we make 8.x a bridge version so it's not a sudden deprecation, and whether, if we did that, we should have it continue to be a full split like it is, or if we could just require the Illuminate Collection package and then alias it to Tighten and then call it a day?
Activity
mathieutu commentedon Apr 21, 2020
Actually, stopping releasing would not bother me. The used version would be still usable, without problem.
However, if you want to keep a bridge, we can just require the illuminate/collection in the package, and extends the laravel classes in this ones, with a deprecation notice?
mattstauffer commentedon Apr 21, 2020
Yah, that's what I was suggesting in my final paragraph. I wonder if that would give some authors an easier transition--and that way they could also more slowly deprecate their reliance on Collect, instead of requiring everyone to upgrade to Laravel 8.
mathieutu commentedon Apr 21, 2020
OK, I thought aliasing the classes.
I'm thinking of what could be the difference, and the benefit of keeping the bridge.
If release stops, nothing will change for an existing project, because the tag will protect them.
BUT if the final project have conflict version with Laravel 8, the conflict will occur the same if we require
illuminate/collections:8.0in this package. So it doesn't fix the upgrade problem. If you're on laravel 7, you will not be able to requiretightenco/collect:8.0.So, if I'm not wrong, updating from
tightenco/collect:7toilluminate/collections:8ortightenco/collect:8(which is finally the same in term of dependencies) would imply for package maintainer that the package will not be installable anymore in Laravel < 8 projects.And this could be a problem!
mattstauffer commentedon Apr 21, 2020
So, Valet currently requires this:
Is there an easy solution for requiring "^Collect 6.0 OR collect ^7.0 OR illuminate/collection ^8.0"?
I figured there wasn't, so we would basically give folks the ability to bump their requirements to "collect ^6.0 || ^7.0 || ^8.0" immediately, then spend the entire 6 months of the 8.0 release timeline preparing to move their product over to 8.0 and excluding their new releases from using Collect (and therefore from being used on pre-8.0 projects).
mathieutu commentedon Apr 22, 2020
Yeah, actually it can be a good compromise.
But this shows us an unexpected issue of creating an illuminate/collection which is used by default in laravel. You can't use anymore the last collections methods in an old laravel project...
Don't know if we could do something about that. 🤔
mattstauffer commentedon Sep 7, 2020
My current thinking about the deprecation strategy:
Give folks that depend on
collectat least one, but likely two, major versions ofCollectionsbefore we phase Collect out.The goal:
Any packages depending on Collect will be able to replace the Collect dependency with an
Illuminate/Collectionsdependency in a year, at which point requiringilluminate/collections:^8.0won't force their users to upgrade nearly as much as that same constraint would today.Tasks right now:
upgrade.shlaravel-8-ongoingbranchlaravel-8-ongoingas our ongoing foundation like we normally would with any new major version upgradev8.0.0releaseTasks soon-ish:
Tasks in one year:
illuminate/collectionsas an alternativestevebauman commentedon Sep 8, 2020
This is awesome, thanks @mattstauffer! I have a package out right now requiring this, so I really appreciate the
v8.0release while I prep my own majorv2release requiringilluminate/collect.mattstauffer commentedon Sep 8, 2020
Glad to hear it @stevebauman!!