Figure out the best deprecation pattern for Laravel 8.0

[mattstauffer]

https://github.com/laravel/framework/pull/32478

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?

[mathieutu]

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]

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?

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]

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.0 in this package. So it doesn't fix the upgrade problem. If you're on laravel 7, you will not be able to require tightenco/collect:8.0.

So, if I'm not wrong, updating from tightenco/collect:7 to illuminate/collections:8 or tightenco/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]

So, if I'm not wrong, updating from tightenco/collect:7 to illuminate/collections:8 or tightenco/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.

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]

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]

My current thinking about the deprecation strategy:

Give folks that depend on collect at least one, but likely two, major versions of Collections before we phase Collect out.

The goal: Any packages depending on Collect will be able to replace the Collect dependency with an Illuminate/Collections dependency in a year, at which point requiring illuminate/collections:^8.0 won't force their users to upgrade nearly as much as that same constraint would today.

Tasks right now:

• [x] Update the upgrade.sh
• [x] Update the readme to mark it as deprecated and describe the deprecation strategy
• [x] Tweet about the deprecation strategy
• [x] Make a new laravel-8-ongoing branch
• [x] Set laravel-8-ongoing as our ongoing foundation like we normally would with any new major version upgrade
• [x] Push out a v8.0.0 release

Tasks soon-ish:

• [ ] Fix the jankiness matt introduced in upgrading upgrade.sh

Tasks in one year:

• [ ] Tweet out about the upcoming abandonment
• [ ] Update the readme explaining the situation
• [ ] Mark the package as abandoned (https://getcomposer.org/doc/04-schema.md#abandoned), suggesting illuminate/collections as an alternative

[stevebauman]

This is awesome, thanks @mattstauffer! I have a package out right now requiring this, so I really appreciate the v8.0 release while I prep my own major v2 release requiring illuminate/collect.

[mattstauffer]

Glad to hear it @stevebauman!!