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

[ademarco]

Problem

While creating the 1.4.0 release of this project this line was changed:

This resulted in broken builds for all packages that depended on behat/mink-selenium2-driver: 1.3.x-dev such as Drupal core and many others. In turn this resulted in several CI/CD builds to fail with the following message:

  Problem 1
    - webflo/drupal-core-require-dev 8.7.x-dev requires behat/mink-selenium2-driver 1.3.x-dev -> no matching package found.

Also, we cannot simply fix our composer.json files by upgrading it to 1.4.x-dev since builds that depends on current or previous versions of, say webflo/drupal-core-require-dev, have no way of fixing that dependency, other than forking this project, creating a 1.3.x-dev branch and update all their composer.json by adding a custom repository information.

Proposed solution

The proposed solution is to create an actual 1.3.x-dev branch on this project, branching off the correct commit hash, this branch will then be published on Packagist, allowing all projects to access it.

[oleg-andreyev]

Depending on dev version is not quite correct As soon as @stof will release 1.4.0, you'll be able to use 1.4.0 as temporary solution you can use dev-master#3ab9f315e9ad63cc518ccc72910754fedd6de015

[oleg-andreyev]

@aik099 @stof as temporary solution from our side, let's create 1.3.x-dev branch which should be branched from commit before 3ab9f31

[ademarco]

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.

[stof]

An branch alias for master will change over time. And it will always be published (otherwise the alias is useless). The whole point of the alias is to be able to depend on ^1.3.0@dev, to get that code which will use dev-master for now, but will match future releases too (and will also match the bumped alias).
Defining exact-version constraints relying on a branch alias is very fragile, and cannot be covered by a BC policy (or we would have to never change the library anymore, once we define a branch alias for master).

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. If we were branching 1.3.x today, it would have to be from the last published 1.3.x tag (to create a 1.3.(x+1) hotfix).

[ademarco]

@stof so the correct thing to do is to branch 1.3.x-dev from 1.3.1 (commit 473a9f3) and then create 1.3.2 as an hotfix on that branch, correct?

[Dropa]

Projects created on top of https://github.com/drupal-composer/drupal-project at least explodes by this change.

Maybe just add one more alias, where 1.3.x-dev just points to 1.3.1?

Edit: assuming that latest 1.3.x-dev before update of master alias was not ahead of 1.3.1

[stof]

well, the thing is, we don't have something to hotfix as 1.3.2, and so we don't need such 1.3.x branch.
Defining a requirement on an exact match of a dev branch alias is simply not something that webflo/drupal-core-require-dev should do, and this is the place where things should get fixed.

[ademarco]

Yeah the problem is that that version constraints is in old webflo/drupal-core-require-dev tags, which are used on all sort of builds.

For what is worth this actually fixes it on the "host project", meaning the project that depends on webflo/drupal-core-require-dev:

        ...
        "webflo/drupal-core-require-dev": "~8.6",
        "behat/mink-selenium2-driver": "1.4.x-dev as 1.3.x-dev"
}

Edit: since people are linking at this comment in PRs I'm linking here the workaround we ended up using in our projects, which is slightly more refined that this one above. Check #313 (comment)

[stof]

well, if webflo/drupal-core-require-dev fixes its requirement and releases a new 8.x version, this will fix it for your project. and it would be the right fix to do, rather than forcing another project to create additional maintenance work (and again each time in the future if this package keeps doing the same) to workaround a situation created by a package that we don't use.

[zuernBernhard]

Webflo will still be on vacation until 11.09.2019 ...

[timmillwood]

We don't depend on webflo/drupal-core-require-dev but in a similar way are depending on 1.3.x-dev in 4+ branches in around 100 repos.

A 1.3.x would really help us in the short term as we look at rolling out an update to all those repos.

[stof]

Well, repos which use a composer.lock are not broken by this change until the time you run a composer update (at which point you can fix the constraint too)

[JeremySkinner]

We have a lot of projects broken by this because we depend on webflo/drupal-core-require-dev which we install during our CI process. @ademarco's workaround (aliasing 1.4.x-dev as 1.3.x-dev) works well, although does mean having to update every project.

It'd be good if a 1.3.x-dev alias could be recreated and pushed out again as this is going to be a problem for a lot of people.

[Boegie]

        "behat/mink-selenium2-driver": "1.4.x-dev as 1.3.x-dev"

I think we should play it a bit more safe by not using a (possibly moving) 1.4.x-dev but maybe a commit SHA that will be static in time?

I've gone with one that wasn't updated recently, since that was probably(?) used for 1.3.x-dev a long time:

    ...
    "behat/mink-selenium2-driver": "dev-master#a38512485e905738321f793b3acd3e7411a85101 as 1.3.x-dev",
    "webflo/drupal-core-require-dev": "~8.7.0"
    ...

[...] although does mean having to update every project.
It'd be good if a 1.3.x-dev alias could be recreated and pushed out again as this is going to be a problem for a lot of people.

Of course, this would be less work for a lot of people. (Not saying using a -dev tag in webflo/drupal-core-require-dev was the best plan to begin with)