Join GitHub today
[WIP] Ignoring pre-release status when checking against resolved packages #2474
Ignoring pre-release status of a new requirement when checking it against packages that have already been resolved. #2471
The thinking is that if something dragged in a pre-relase version (e.g. the dependencies file) then we actually want pre-release of that package.
In my testing this seems to work. Even if the pre-release status is ignored in IsInRange(), the actual pre-release versions are still compared, so a requirement ">=2.0" will fail if a resolved package has version "2.0-pre". Could use some checking from someone who knows the code better though.
I want to add some test-cases to this before we merge it :)
We can add these to the resolver unit tests...
referenced this pull request
Jun 30, 2017
@forki if I read the change correctly, you only allow pre-release on packages in the dependencies file? Might that not be too limiting? I was actually happy to allow pre-release unconditionally here since it has already been resolved. We're only checking if the new requirement is ok here, so the proper thing to do is to trust that the resolution is correct and check the version as it is.
Just want to raise the question. If you say this is the way it should be, I'll take your word for it :)
@zzdavid yes it's actually needed to restrict it. Otherwise you will end up with following situation:
^^ this would be valid with your change, but I think it should not
@forki It looks like a bug in package A (without prerelease) if it depends on a prerelase of B. With package A in pre-relase it makes sense.
with the resolution
The resolution looks correct to me, at least if A and B are developed together, and worked in 4.8.8 but will fail now.