You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Well, before making new releases for Mink packages, I would like to make CI green for the different drivers (IIRC, the Selenium2Driver CI has issues currently)
Instead of using approach, where driver releases must be in sync with Mink releases itself (suggested in #757 (comment)) we can use different approach: drivers and Mink itself are released independently as long as no BC breaks in driver API happen.
If that sounds good enough we need to:
inspect all commits made since last release to create change log and look for BC breaks
depending on BC break presence we decide to make new release as 1.7.2 (no BC breaks) or 2.0.0 (has BC breaks)
P.S.
That would make people in this discussion happy even with 1 semi-active maintainer.
if we have no BC breaks, we should not tag it as 2.0. That would make it painful for users, as any library depending on Mink would have to be updated first to allow the new major version, without any need for a major version.
@BigZ@adiq@aik099 are you all directly requiring behat/mink: "1.7" in your projects?
i use dev-master
we can use different approach: drivers and Mink itself are released independently as long as no BC breaks in driver API happen
yes please. it's in the composer "suggest section" and mink is not tied to a specific version of them.
if we have no BC breaks, we should not tag it as 2.0. That would make it painful for users, as any library depending on Mink would have to be updated first to allow the new major version, without any need for a major version.
@kochen Sorry for the late response. Currently, I am using dev-master pinned to a specific commit for better stability. The release is not crucial, but I guess everyone would prefer to use versioned tag then branch even if it's development dependency only.
I am also using dev-master now. Thanks @adiq.
Here's my working set of packages that does not cause conflicts with SF 4.3.8 https://pastebin.com/9q6niy4q
However, it's not a good practice to change requirements within patch releases (eg. 1.0.x), because dependants should be able to upgrade without any problems if a security release is published.
Therefore it should be possible to just tag a new minor version.
You can install them as friends-of-behat/mink, friends-of-behat/mink-extension and friends-of-behat/mink-browserkit-driver packages and they will replace corresponding original packages, so that dependencies resolving will still work if some other packages require the original ones.
Overall, it'd be best if someone could take care of Mink-related libraries in their source repositories, please give me a ping when it supports Symfony 5 so I can abandon my forks.
ruudk, oleg-andreyev, DZunke, Headd2k and abienvenu
All the community really wants to move forward. Let's make americaMink great again!
If maintainers feel that they have enough of supporting Mink organization, I'd like to volunteer, so please grant permissions.
@oleg-andreyev , for me personally it's time. I no longer can afford to spent hours of my personal time, I've used to before, on OpenSource. I can somehow allocate 1-2 hours a week and not even in each week.
To move things forward (my personal view of the situation):
once that done we can drop support for some PHP versions and remove any workarounds for supporting different PHPUnit versions that were only working on removed PHP versions
then we can focus on adding support for new Symfony component versions
then we can try fixing builds on every supported PHP version
then we finally can release Mink & drivers so avoid people using forks instead of main repo
release would hopefully would make Drupal users happy
To make project maintenance harder PRs are coming in, that do the same things in different ways, e.g.:
removal of non-supported (by php.net) PHP versions
adding support for new Symfony versions
adding support for PHPUnit versions
There is no clear vector that community can use to help moving project forward.
Activity
pamil commentedon Feb 14, 2018
Is there anything that needs to be done to tag a new release?
adiq commentedon Feb 14, 2018
I think there is nothing to do, as 808702d fixes the dependencies problem. I'll try to test it on real project and will let you know.
stof commentedon Feb 14, 2018
Well, before making new releases for Mink packages, I would like to make CI green for the different drivers (IIRC, the Selenium2Driver CI has issues currently)
kochen commentedon Apr 21, 2018
@adiq did you manage to get Sessions to work?
I'm getting:
See: Behat/MinkExtension#321
and is
$sessions
(https://github.com/minkphp/Mink/blob/master/src/Mink.php#L36) is actually empty... :/bartonhammond commentedon May 8, 2018
I'm getting same error
Specify session name to get (InvalidArgumentException)
. Any update?adiq commentedon May 8, 2018
I will look into this when I will have some spare time. Did you try to revert mentioned commit and see if the issue persists?
bartonhammond commentedon May 8, 2018
I got past that error by adding the line below
DonCallisto commentedon May 25, 2018
Isn't the CI green? I can't see any error.
aik099 commentedon May 25, 2018
@DonCallisto , in the #757 (comment) @stof meant driver repos. Almost all of them are red currently.
DonCallisto commentedon May 25, 2018
Got it, so we should try to fix them IIUC
tristanbes commentedon Jun 29, 2018
Any release planned yet ? It hurts me to require a package as
dev-master
aik099 commentedon Jun 29, 2018
Nothing has changed since #757 (comment). I could really use some help on getting those driver tests green again.
kochen commentedon Oct 18, 2018
That line doesn't seem to do the trick.
I've created a repo that demonstrates the issue: https://github.com/kochen/behat-mink-session (with
travis-ci
).juliendufresne commentedon Dec 23, 2018
This is blocking every projects using symfony/flex with the composer extra config
symfony.require: "4.2.*"
16 remaining items
aik099 commentedon Aug 28, 2019
Actually we can make all people happy here.
Instead of using approach, where driver releases must be in sync with Mink releases itself (suggested in #757 (comment)) we can use different approach: drivers and Mink itself are released independently as long as no BC breaks in driver API happen.
If that sounds good enough we need to:
P.S.
That would make people in this discussion happy even with 1 semi-active maintainer.
kochen commentedon Aug 28, 2019
@aik099 or we tag it has 2.0.0 even without BC breaks and we sail to a fresh (re)start.
stof commentedon Aug 29, 2019
if we have no BC breaks, we should not tag it as 2.0. That would make it painful for users, as any library depending on Mink would have to be updated first to allow the new major version, without any need for a major version.
BigZ commentedon Sep 11, 2019
i use dev-master
yes please. it's in the composer "suggest section" and mink is not tied to a specific version of them.
Definitely. but we have what looks like a BC break there v1.7.1...master#diff-b5d0ee8c97c7abd7e3fa29b9a27d1780L19
(css selector version is set to a minimum of 2.7 when it was 2.1 before)
It's the only one i found, tho. and it might be easy to fix.
adiq commentedon Sep 21, 2019
@kochen Sorry for the late response. Currently, I am using
dev-master
pinned to a specific commit for better stability. The release is not crucial, but I guess everyone would prefer to use versioned tag then branch even if it's development dependency only.Ping me if I could be helpful in some way here 😉
pacid commentedon Nov 15, 2019
I am also using dev-master now. Thanks @adiq.
Here's my working set of packages that does not cause conflicts with SF 4.3.8
https://pastebin.com/9q6niy4q
pamil commentedon Nov 19, 2019
@BigZ requiring a higher version of a dependency is not a BC break - if you're stuck on CSS Selector 2.1, then Mink won't upgrade, so nothing will break. It's same for PHP version: https://www.doctrine-project.org/2017/07/25/php-7.1-requirement-and-composer.html
However, it's not a good practice to change requirements within patch releases (eg. 1.0.x), because dependants should be able to upgrade without any problems if a security release is published.
Therefore it should be possible to just tag a new minor version.
DonCallisto commentedon Nov 24, 2019
Meanwhile also sf5 is out there
oleg-andreyev commentedon Feb 10, 2020
@stof @aik099 what's holding us from creating new release?
Build on MinkSelenium2Driver is almost green. Seems that it got broken recently:
https://travis-ci.org/minkphp/MinkSelenium2Driver/builds/639627599?utm_source=github_status&utm_medium=notification
All the community really wants to move forward. Let's make
americaMink great again!If maintainers feel that they have enough of supporting Mink organization, I'd like to volunteer, so please grant permissions.
pamil commentedon Feb 11, 2020
If anyone needs to install it now, I forked several Mink-related repos to FriendsOfBehat and made their build passing for Symfony ^4.4|^5.0.
https://github.com/FriendsOfBehat/Mink
https://github.com/FriendsOfBehat/MinkExtension
https://github.com/FriendsOfBehat/MinkBrowserKitDriver
You can install them as
friends-of-behat/mink
,friends-of-behat/mink-extension
andfriends-of-behat/mink-browserkit-driver
packages and they will replace corresponding original packages, so that dependencies resolving will still work if some other packages require the original ones.Overall, it'd be best if someone could take care of Mink-related libraries in their source repositories, please give me a ping when it supports Symfony 5 so I can abandon my forks.
aik099 commentedon Mar 5, 2020
@oleg-andreyev , for me personally it's time. I no longer can afford to spent hours of my personal time, I've used to before, on OpenSource. I can somehow allocate 1-2 hours a week and not even in each week.
To move things forward (my personal view of the situation):
To make project maintenance harder PRs are coming in, that do the same things in different ways, e.g.:
There is no clear vector that community can use to help moving project forward.
// cc @stof
BigZ commentedon Jun 10, 2020
finally done, 2 years later B) thanks @stof !
Now waiting for phpunit 9 support :D
stof commentedon Jun 10, 2020
Mink does not have a PHPUnit dependency. So I don't see the issue here (Mink uses PHPUnit by itself, but that has no impact on projects using Mink).
stof commentedon Jun 10, 2020
I'm closing this ticket, as Mink 1.8 has been released (and discussions about Behat extensions are out of the scope of this repo)