search

laravel / browser-kit-testing

Provides backwards compatibility for BrowserKit testing in the latest Laravel release.
MIT License
509 stars 75 forks source link

[7.x] Allow to install Laravel 8. #130

Closed crynobone closed 4 years ago

crynobone commented 4 years ago

Signed-off-by: Mior Muhammad Zaki crynobone@gmail.com

driesvints commented 4 years ago

@crynobone We've actually recently opted to make use of the as syntax when working with versions which are still in development. Can you try the below instead?

"laravel/framework": "dev-master as 7.0"
crynobone commented 4 years ago

That would mean no package can ever try to continuously test compatibility on upcoming releases.

with Laravel 7, spatie started tagging release a day before the official 7.0.0, some was already doing it a week before.

Compare that with Laravel 6, everyone was only releasing Laravel 6 compatibility after 6.0.0 was released.

I'm targeting dev-master because it's not the active release branch for both project. The idea is mainly to provide branch that user can point if they want to test against 8. Making an alias doesn't solve this because you are not getting v8

driesvints commented 4 years ago

We can't report bug early because it's loading 7.x

But that's not true? You're loading dev-master which is v8. The as part only mimics it as v7.

Any breaking change can only be handled when Laravel 8 is only closed to public release.

We're going to add the new version constraint about 2 weeks before we do the new Laravel 8 release so that's two weeks which you can use to fix any breaking changes in your package.

with Laravel 7, spatie started tagging release a day before the official 7.0.0, some was already doing it a week before.

I don't recommend that but we can't stop people from doing that. But given the fact that we will add the constraints two weeks before we do the new major Laravel release this should "technically" be okay.

I'm targeting dev-master because it's not the active release branch for both project.

Before we recommended using the as syntax we did the new major releases on the active release branch so if this PR is accepted it'll have to go to the 6.x branch of this repo.

driesvints commented 4 years ago

That would mean no package can ever try to continuously test compatibility on upcoming releases.

Btw about this, you can if you do this:

"laravel/framework": "dev-master as 7.99"

Then use 7.99 as your constraint for the upcoming release.

crynobone commented 4 years ago

But that's not true? You're loading dev-master which is v8. The as part only mimics it as v7.

That is true if I'm the root package, but I'm not. I mention before that no package can ever try to continuously test compatibility on upcoming releases and what I meant was I planning to create a branch for orchestra/testbench-browser-kit and orchestra/testbench-dusk to allow any packages to target tests against Laravel 8.

Screenshot 2020-03-30 at 5 19 59 PM

https://getcomposer.org/doc/articles/aliases.md#require-inline-alias

While yes I can do "laravel/framework": "dev-master as 7.99" but any package that want to test against Laravel 8 would have to do the same.

driesvints commented 4 years ago

I'm gonna re-open this so Taylor can have a look and decide.

GrahamCampbell commented 4 years ago

The problem is that it's a bad idea for a package to do a release claiming compatabilty with laravel 8, and then remove compatability later. Because... you simply can't do that.... the old version is still there. It's fine for upcoming packages to have v8 in them, so long as they are never tagged until v8 comes out, but this browser-kit package does tags all the time.

driesvints commented 4 years ago

There's also a problem to only allow installs from dev-master of a first party package with a v8 tag and then still tag a current stable release later with v8 support when v8 is out. If third party packages weren't expecting to having to maintain a current stable release that could go sideways.

crynobone commented 4 years ago

Alright then, I'm shutting down testbench dev-master until 2 week before 8 release.

driesvints commented 4 years ago

@crynobone I'd still like to have Taylor's opinion about this so re-opening.

taylorotwell commented 4 years ago

This is the only practical way to do this afaik.

driesvints commented 4 years ago

I'll update all the libraries soon then.

driesvints commented 4 years ago

And I'll roll this out on the current release branches.

driesvints commented 4 years ago

@crynobone we decided to just do the master branches of browser-kit-testing and dusk for now.