MinkSelenium2Driver: Change of master branch alias to 1.4.x-dev breaks packages depending on 1.3.x-dev

I’ve created 1.3 branch. I can confirm, that 1.3.x-dev version now exists on Packagist: https://packagist.org/packages/behat/mink-selenium2-driver

I have tested creating 1.3.x, and it works fine. It would be fine to create 1.3 instead. Please create one of these branches.

Drupal cannot change the constraint from 1.3.x-dev to something else. The constraint is recorded forever in every stable tag from Drupal 8.6.0 to 8.7.7 (just came out today). Anyone who tries to install an old stable version with Composer will run into problems.

It is not a problem to create a 1.3.x branch that will never have another 1.3 release on it. It is an ordinary and expected thing that, if you depend on a branch such as 1.3.x-dev that you may get commits that belong on 1.4.x, because 1.3.x-dev means the same thing as dev-master (or did, a short while ago), which means everything newer than the last stable release on the 1.3 line. I can understand your point about not wanting the 1.4.x commits on 1.3.x-dev if you were going to maintain the 1.3.x branch. However, we are not asking you to maintain the 1.3.x-dev branch; we just need it to repair the sins of the past. When 1.3.x-dev did exist, it had commits on it destined only for 1.4.x. We do not want that history rewritten.

As soon as there is a stable 1.4 release, we will move Drupal to that (similarly with a new stable 1.7 release on behat/mink). We are not looking to solve the problem of how to abuse using the minor release dev branches in the future. Drupal is going to stop doing that. We only want to solve the problem of the past, where Drupal is using 1.3.x-dev constraints in old existing stable tags.

Thank you for your understanding and help.

Quite a lot of people here are “blaming” webflo but in reality this issue is in Drupal core: https://github.com/drupal/drupal/blob/8.8.x/composer.json#L14 and that is what webflo copies over from require-dev to require. So the expectation that webflo should have to fix this for Drupal is not correct. It should be fixed in Drupal core.

Update: Drupal core issue: https://www.drupal.org/project/drupal/issues/3078671

@stof ^1.3@dev is what we should have done, had we realized that 1.3.x was a branch alias and not a true development branch, but the issue now is that even if we were to update our constraint, we wont be able to affect all of the existing users who currently have 1.3.x-dev in their composer.json/composer.lock files. Our experience shows us that we’ll be receiving support questions on this issue for many years to come.

So,

creating a 1.3.x branch pointing to commits that will only ever be part of a 1.4.0 release

Is what we’re asking for, as those commits used to appear to us to be part of 1.3.x until the branch alias changed, which effectively backdated all of the commits from 1.3.1 onwards as being on the 1.4.x line.

We definitely appreciate your help in getting this resolved.

Solutions for Drupal core are being discussed at https://www.drupal.org/project/drupal/issues/3078671

@JeremySkinner While I understand this issues, it’s not fault of Mink maintainers. You should use -dev on your own risk, maintainer cannot guarantee here anything.

@dbosen It’s open source, people are spending their free time on this… If you see that package wasn’t released for 3 years, maybe we as a community need to help maintainers, especial if package is heavily used in your project

You are asking the Mink maintainers to fix a situation they are not responsible for at all here.

I appreciate that webflo/drupal-core-require-dev have done the wrong thing and should fix this, but deleting a public alias that downstream packages may depend on (even if they technically shouldn’t) is analagous to deleting a release that people already depend on (and is precisly why most package managers don’t allow deletion of packages once they’ve been published), so I do think mink does have some responsibility here.

I appreciate that you’re busy though, and we do have a workaround so it’s not a showstopper.

@oleg-andreyev I appreciate your point of view, but will respectfully disagree. Part of choosing to maintain and support an open source project involves understanding how the community are using that project and being empathetic even when the community perhaps starts using the project in a way that wasn’t intended. As someone who runs a reasonably popular oss project, there have been times where I’ve changed something that I believed was in the best interest of the project, that has caused pain for the community, and in those cases I always try to take time to consider the feedback and re-examine those choices if necessary. At the end of the day, our oss projects exist to help developers deliver value.

In this particular case, a large portion of the Drupal community depend on drupal-core-require-dev, probably without even realising that it had a dev dependency on mink (I know I didn’t). Yes, drupal-core-require-dev Drupal maybe did the wrong thing by depending on dev, and yes, they should fix that, but that doesn’t change the fact that choosing to remove the alias has had a real world negative impact on a lot of people. I do appreciate that OSS maintainers’ time is precious (believe me I really do understand that first-hand) and you have to prioritise, but I’d still ask that you’d consider restoring the alias as a gesture of goodwill until Drupal can be updated, as that would literally help a lot of people.

it would be good if webflo/drupal-core-require-dev could fix their mess instead of forcing us to create our own mess to workaround it. You are asking the Mink maintainers to fix a situation they are not responsible for at all here. And anyway, I won’t have time to do that right now (and if I had time to work on Mink right now, I would still rather work on preparing things for a next release than working on such workaround).

@greg-1-anderson sure, we won’t got back! I hope that we all learned a lesson and will never have this issue again.

Just wondering if comment 527995474 by @aik099 means there will be a 1.3 branch created here (using either 8684ee4 or 0a09c43)? @ryanaslett actually asked for the later commit. I’m indifferent, as long as we have the branch.

Just to be certain, I forked this repo and used a vcs repository to test.

This solved the problem, allowing projects to include commit 8684ee4 as 1.3.x-dev:

$ git checkout -b 1.3.x 8684ee4
$ git push origin 1.3.x

@aik099 Both @ryanaslett and I were saying the same thing. I apologize that my note was very confusing.

Save the day:

git branch -b 1.3.x  8684ee4

Make things worse:

git branch -b 1.3.x 1.3.1

I didn’t test that the branch name 1.3.x is the correct name to be selected by 1.3.x-dev, but I believe that’s right.

Yes, Drupal was using power tools without safety glasses and lost an eye. This is not the fault of minkphp/MinkSelenium2Driver.

It would be possible to fix Drupal by creating a perpetual 1.3.x-dev branch; however, in order for that to actually fix things, the 1.3.x-dev branch would have to point at 8684ee4e634db7abda9039ea53545f86fc1e105a or later.

Branching 1.3.x-dev from a commit which will never be part of a 1.3.x release (as this commit will be part of 1.4.0) will not happen.

While your position here is reasonable as far as policy and procedure are concerned, I would ask that you be a little flexible here. Note that when the 1.3.x-dev branch did exist, it did have commits that would never be part of any 1.3 stable tag. I therefore put forward the suggestion that it would not be horrible to base 1.3.x off of 8684ee4. To use an earlier commit (e.g. the 1.3.1 tag) would cause old stable tags of Drupal to revert features that were at one time present in 1.3.x. This would be akin to rewriting git history, as your new 1.3.x branch would be different than the old one used to be. This would be far worse than the current state of affairs. Now, builds are breaking because 1.3.x-dev does not resolve. If you re-created 1.3.x-dev with different contents, then Composer would start working again, but code based on old stable Drupal tags would stop working (after the next composer.lock update). This would be very confusing and damaging.

Again, it is Drupal’s fault for using a dev reference in a stable tag, but please please, do not make a 1.3.x-dev based on the 1.3.1 tag. It would be better to do nothing than to do that.

this is useless. A dev-master branch alias has no effect outside the master branch.

@stof , here my suggestion in more details:

1. master branch have alias from dev-master to 1.4.x
2. 1.3 branch have alias from dev-1.3 to 1.3.x

Since Packagist will read composer.json in all of the branches it will end up creating 2 aliases:

• one pointing to master branch
• another one pointing to 1.3 branch

Are you certain this won’t work?

but then, are we expected to create the same mess again each time we release a minor version ?

Nope. We should mention in README, that people shouldn’t depend on aliases at all. If they will, then we promise no support.

Please just create a 1.4.0 tag, so drupal can update it’s composer file to fix this mess.

To summarize I see several solutions (in above comments) that involve changing composer.json file in projects, that use Mink. When implemented they will allow using master branch and not get all tests broken because of an alias change.

P.S.

• As an open-source project nothing is really guaranteed except likely passing tests on Travis CI.
• If somebody does have free time to spend on moving this project forward, then we’re (as maintainers) looking forward to it.

tbh. I also do think, that the Mink maintainers are partially responsible for this mess. As you did not release a new version for three years, projects were more or less forced to use the -dev tag.

Thank you @oleg-andreyev ! I realize that that’s not ideal but that alias was published on Packagist and people started using it relying on the fact that, since it was published, it would not be removed.

I’d consider keeping this as a permanent solution for the issue, also in future, when 1.5.0 will be released.