Prerelease packages won't used during resolving

Description

I have two packages A and B and the package A has a dependency on B.

My dependency file looks like

source Externals/NugetStore

nuget PackageA
nuget PackageB 1.0.11204-custom

With paket 4.8.8 the paket lock file looks like

NUGET
  remote: Externals/NugetStore
    PackageA (1.0.11250)
      PackageB (>= 1.0 < 2.0)
    PackageB (1.0.11204-custom)

But now with paket 5.2.5 I get the following output:

Paket version 5.2.5
Resolving packages for group Main:
 - PackageB is pinned to 1.0.11204-custom
 - PackageA 1.0.11250
   Incompatible dependency: PackageB >= 1.0 < 2.0 conflicts with resolved version 1.0.11204-custom
Performance:
 - Resolver: 356 milliseconds (1 runs)
    - Runtime: 292 milliseconds
    - Blocked (retrieving package details): 63 milliseconds (2 times)
    - Not Blocked (retrieving package versions): 2 times
 - Disk IO: 42 milliseconds
 - Runtime: 1 second
Paket failed with:
-> There was a version conflict during package resolution.
     Resolved packages:
      - PackageB 1.0.11204-custom
     Conflict detected:
      - Dependencies file requested package PackageA: >= 0
      - Available versions:
        - (1.0.11250, [Externals/NugetStore])

     Please try to relax some conditions or resolve the conflict manually (see http://fsprojects.github.io/Paket/nuget-dependencies.html#Use-exactly-this-version-constraint).

Repro steps

Use the Repro.zip

1. .paket\paket.bootstrapper.exe

2. .paket\paket.exe install

Expected behavior

Because the PackageB is pinned I would expect that this is taken as long as it fits into the constraints. To pin the package is kind of testing new prereleases. I wonder how this should be able without repackaging all packages. A similar issue is described in #2459, but the recommendation that the package has to specify that it allows this as dependency does not seem valid to me. The definition of the version specifier in the nuspec file does not allow to specify more than just version numbers.

Actual behavior

Please provide a description of the actual behavior you observe.

Known workarounds

1. Switch back to paket 4.8.8
2. Pin all packages (anti-pattern)

[matthid]

@Stift can you add those to https://github.com/fsprojects/Paket/pull/2474 as unit tests for the resolver?

[forki]

ok forget my proposal for now. Maybe it’s too much for this case.

other question: why do we say

 Incompatible dependency: PackageB >= 1.0 < 2.0 conflicts with resolved version 1.0.11204-custom

when it’s actually in the range?

I think we should only exclude 1.0.0-custom and 2.0.0-custom