You can clone with
HTTPS or Subversion.
It looks like a replacement does not replace the aliased version anymore based on the branch alias: https://travis-ci.org/FriendsOfSymfony/FOSJsRoutingBundle/jobs/17469579
Added a failing test for #2626
Not sure if related but I have been having trouble requiring an exact package version based on the git hash (dev-master#hash) - this resolves as dev-master for me...
@kbond This has nothing to do with this issue. the reference locking is not an alias at all. and it is logical that it uses the dev-master metadata. It is only a hack at the level of the git installation (which also means that a dist download would not use this reference locking). You should avoid using such locking whenever possible
I see, so it only works correctly if I include the package as a "custom" repository?
no, it only works fine if the dependencies of dev-master are the same (or at least compatible) with the dependencies you expect, and you install from source. The reference locking has no impact at all on the dependency resolution
This doesn't seem to be an issue at all (see FriendsOfSymfony/FOSRestBundle#656 and FriendsOfSymfony/FOSRestBundle#705).
@xabbuh It is an issue. FOSRestBundle simply managed to find a workaround. but it is still broken. I even managed to write a testcase reproducing it (see the linked PR)
@xabbuh to be clear, FOSRestBundle should not need to explicitly alias symfony/event-dispatcher master to 2.5. The replacement of self.version in symfony/symfony should take the branch alias into account (and it was taking it into accoutn previously)
@stof I understand what you mean. But as far as I can see, the problem is with the symfony/framework-bundle dependencies which don't require self.version but ~2.5.
@xabbuh No. Requiring ~2.5 is perfectly valid. the issue is that the optimization done in Composer a few weeks ago broke the resolution of dependencies in this case. It is definitely a composer bug. If you use composer 1.0-alpha7, the testcase above will pass
@stof But how should that work? 2.5 isn't stable yet. So, the FrameworkBundle requires a dev dependency which doesn't work for FOSRestBundle where minimum-stability isn't set. The minimum-stability flag of the FrameworkBundle shouldn't be taken into account when it isn't the root project.
@xabbuh the requirement on symfony/symfony allows to install symfony/symfony:dev-master. and the combination of branch-alias+replace should satisfy the match (if the bundle was depending on symfony/symfony: ~2.5 and you require dev-master, it would work even if 2.5 is not stable yet, if we forget the fact that it would be broken because of symfony replacing FrameworkBundle).
The issue is that the optimization done a few weeks ago to limit the packages set in the solver based on root requirements does not take care of aliases of selected packages.
@stof I was confused since FOSRestBundle doesn't require symfony/symfony. But now I understand the issue.
@xabbuh hmm, in their case, they are indeed not requiring it (which also means that they are not really testing against Symfony 2.2 as the 2.4 packages will match the dependencies of FrameworkBundle 2.2 and be used). But there is still a bug in composer anyway
@stof Yes, I can confirm the bug. It's easily reproducable with a composer.json like this:
Works with Composer 1.0.0-alpha7 but not with 1.0.0-alpha8.
@xabbuh yeah indeed. And it is exactly what the testcase I submitted is doing
@stof Ah, didn't see the test case yet. Sorry for the confusion.
Please see #2805 for a potential fix.