Hi @mrjoel

This is something that we thoroughly discussed and iterated, based on user feedback and expectations.
At the moment it doesn't seem a bug, but expected design:

For [>=1.0 <2], the value 1.0.0-pre.1 should not be included, while 2.0-pre.1 should be

The logic is that 1.0.0-pre.1 is a 1.0 release. It is not a 0.9 one, but a 1.0 one

For [<3.2.1], the value 3.2.1-pre.1 should be included

Likewise, the 3.2.1-pre.1 is also a 3.2.1 release.

So the logic to include and exclude them is correct.

I'll also like to clarify that in Conan 2, hardcoding the resolution to prereleases in requires is not the most recommended approach, and an new conf core.version_ranges:resolve_prereleases (see https://docs.conan.io/2/devops/versioning/resolve_prereleases.html#handling-version-ranges-and-pre-releases)

I'll give an example that makes this more evident:

• A team has a project with some dependency to one of their packages mypkg/[>=1.0 <2.0]
• They happily release patches and minors, that are API compatible and move forward to the mypkg/1.3.8 for example
• When they are not sure about some API compatible but possibly behavior breaking releases like mypkg/1.4, they create prereleases like mypkg/1.4-pre.1
• The conf core.version_ranges:resolve_prereleases is activated whenever the CI or developers want to test these prereleases
• Now the team starts to work in an API breaking major release, because they need to move forward a big change in mypkg
• They start to work in that version, it will take time, so they start to create alpha prereleases like mypkg/2.0-alpha.1
• If these pre-releases are automatically accepted by the mypkg/[>=1.0 <2.0] range, that will break all the consumers that were depending on mypkg
• Even if they explicitly said "we don't want to depend on the next API breaking major releases 2.0 (<2.0, strictly lower than 2.0)

Then, it was concluded that even if 2.0-alpha < 2.0 in strict version ordering, the version ranges like mypkg/[>=1.0 <2.0] are semantically equivalent to mypkg/[>=1.0- <2.0-], that is, including prereleases in the lower bound for >=, and excluding prereleases in the upper bound for strictly lower than < bounds.

The logic is that 1.0.0-pre.1 is a 1.0 release. It is not a 0.9 one, but a 1.0 one.

That seems somewhat unfortunate and non-intuitive from a SemVer perspective (1.0[.0] is a specific version, not a collection of multiple versions), but appears to be at least mostly self-consistent. Unless I'm missing something, however, that seems to prevent any range expression distinction based on pre-release values? For example, it appears that one can't write an expression that allows 2.1.0-beta or later, while not enabling usage of 2.1.0-alpha versions.

I'd expect to be able to do something like:

from conan import ConanFile

class PackageC(ConanFile):
    name = "packagec"
    version = "2.1.0-beta"

class PackageD(ConanFile):
    name = "packaged"
    version = "1.0.0"

    def requirements(self):
        self.requires(
            # What I might really want to write, assuming the "alpha is a 2.1.0 release" logic.
            #"packagec/[=2.1.0, include_prereleases]"

            # Using a ranged comparator seems required to permit selection.
            "packagec/[<=2.1.0, include_prereleases]"

            # But - only for less-than-equal, not greater-than-equal?!?
            #"packagec/[=>2.1.0, include_prereleases]"

            # Can't set pre-release lower bound though.
            #"packagec/[>=2.1.0-beta <=2.1.0, include_prereleases]"

            # At best, something approximate like so, but also undesirably includes e.g., -alpha.
            #"packagec/[>2.0.99 <=2.1.0, include_prereleases]"

            # Also works (still not excluding -alpha), although quite
            # non intuitively if expecting a total ordering.
            "packagec/[>=2.1.0 <=2.1.0, include_prereleases]"
        )

This has been important for us with our internal dependencies (detailed below) to more strongly signal to a developer that no compatible version is available and needs to be updated from a remote.

Since that is the case, I'd suggest that at least a documentation update would be important in order to clarify those semantics of range expression comparisons for pre-release and build metadata version sections. In particular, based on my updated understanding, it would be important to clarify the following (adjusted for correctness as needed):

1. Most importantly, clarify that comparators do not operate on the full SemVer value, but only on the "version core" or base version. I find this especially important given the other existing note about how Conan does specifically consider the +build field in ordering or pre-releases (that behavior is definitely appreciated).
2. the include_prerelease option controls whether or not pre-release versions of a package in the cache are considered as available in comparisons (i.e., 2.1.0 will be in the set of available versions if at least one 2.1.0-pre package is present)
3. once the base version has been determined, if include_prerelease is enabled, the latest pre-release available for the determined base version is always selected

I'd further suggest that it would still be greatly beneficial to have finer control within a given pre-release range for a single base version, specifically the ability to have comparators do full (pedantic?) SemVer ordering. If it were added, it would seem to need to be an additional range expression option (strict_compare) or some such for compatibility with the Conan 2 logic above.

I'll also like to clarify that in Conan 2, hardcoding the resolution to prereleases in requires is not the most recommended approach, and an new conf core.version_ranges:resolve_prereleases.

I've seen that and looked into it, however it seems to only enable an all-or-nothing approach (there isn't anything like a [resolve_prereleases] profile to do based on reference pattern matching). We'd like the flexibility to only enable pre-releases of our dependency package when needed, and not other pre-release packages, possibly from other concurrent projects a developer may be working on at the same time.

The pattern we use for this is to have a intermediate meta package which serves as the primary source of requirements. The actual product source conanfile only depends on a matching version of that single dependency meta package. We allow each to develop concurrently, and use git tags to highlight incompatibility points (API changes, etc.) within a development cycle. Both the meta package version as well as the range expression is dynamically determined based on the particular git commit being used.

If a developer is building a development version of the product from git, then we want to be able to specify including prerelease versions for the dependency metapackage, but not other packages, including packages for other products that may also be in the local cache. To do this, we regularly rev dependencies within a development cycle, but only update the dependency when incompatible changes are made, for which we rev the first prerelease as a quasi API compatibility flag within the dev cycle. For example, if moving from using packageb/1.5.9 to packageb/2.0.0 with incompatible changes, we'd rev the providing and dependent git tags to change from 2.1.0-0.dev+123.g0abcdef to 2.1.0-1.dev+124.g0bbbbbb. We leverage some simple logic to transform git-describe to a semantic version, including pre-release and build portions. By doing this, all package versions are readily tracable back to git commit from which they originated, and the proper version is dynamically determined by each of the recipes (only permitting usage of pre-release dependency package if build a pre-release product source tree).

I illustrate below a possible flow within a given development cycle which is enabled by this. It illustrates the pattern - we in no way always have all or even most of the transitions in each cycle, but having the structure to be able to increment when and as needed has been quite beneficial.

Hi @mrjoel

For example, it appears that one can't write an expression that allows 2.1.0-beta or later, while not enabling usage of 2.1.0-alpha versions.

Not sure what you mean, I can add these cases to the test suite, and it works:

# Limits
    ['>=2.1.0-beta', False, ["2.1.0"], ["2.1.0-beta", "2.1.0-alpha"]],
    ['>=2.1.0-beta', True, ["2.1.0-beta", "2.1.0-gamma"], ["2.1.0-alpha"]],
])
def test_range_prereleases_conf(version_range, resolve_prereleases, versions_in, versions_out):

Where versions_in are accepted versions inside the range and versions_out are rejected versions outside of the range.

As you can see, if not using prereleases, 2.1.0 is accepted, but all prereleases are rejected.
But if enabling prereleases, 2.1.0-beta and higher like gamma are accepted, but alpha is rejected.

I am adding this case in the test in PR, just in case.