Carthage: Oddities when parsing versions like v1.0.0-rc.1

[jspahrsummers]

Version: Carthage 0.7.3

Given Nimble's current tags:

a Cartfile with:

github "Quick/Nimble"

will result in version 0.4.2 being used, while

github "Quick/Nimble" ~> 1.0  # Or ==

will result in version 1.0 being used.

Something is wrong in our version parsing, because v1.0.0-rc.1 should either be rejected by the parser, or else considered as newer and better than v0.4.2.

[jspahrsummers]

While investigating an unrelated issue, I've also noticed this happening for RAC's recent tags. Here's the result of logging an invalid DependencyNode:

github "ReactiveCocoa/ReactiveCocoa" @ "v3.0-beta.4" (restricted to ~> 2.4.3)

[pietbrauer]

How would one tackle this?

I tried adding an appendix to SemanticVersion so that you can create one by using SemanticVersion(major: 1, minor: 0, patch: 0, appendix: "alpha") from 1.0.0-alpha. But then the Equatable has to be updated too and one has to consider all the permutations, e.g. "beta" < "pre" (pseudocode).

My current idea is to introduce an enum: SemanticVersion(major: 1, minor: 0, patch: 0, appendix: .Alpha) this makes comparing easier. What other challenges do you see? Do you find that an okish approach?

[aschuch]

I have a similar issue. Given the following tags in my repo:

• 1.0.1
• swift-1.1

swift-1.1 always "wins", although it is not the newest version.

[jspahrsummers]

@aschuch That behavior is correct. After all, how is Carthage to know that those aren't part of the same release series?

I'd recommend renaming the tags, or else using explicit pins instead of open-ended constraints.

[aschuch]

Ok, I didn't know that this was the intended behaviour. Thanks for the heads up, I'll rename the tags.

[jdhealy]

I'm pretty sure I've tracked down the root cause — from CarthageKit's Version:

Consider non-semantic versions (e.g., branches) to meet every version range requirement.

That's causing the non-semantic versions to pass through a filter in the resolver.

[pietbrauer]

@jdhealy I once opened a PR for that and agreed with @jspahrsummers on not doing it: https://github.com/Carthage/Carthage/pull/499

[jdhealy]

Let me clarify: it seems some tag names (including ones without numbers in the name) currently satisfy every version range requirement.

See this gist for a few examples of the oddities in action.

[tonyarnold]

Also, apparently . supersedes -. RxSwift have tagged one of their alpha releases as 3.0.0.alpha.1, which always matches before later beta versions, i.e. 3.0.0-beta.2.

Is that worth fixing in Carthage? It's a mistake on the original repo, right, but you can't shouldn't move tags. Seems to me that . and - should be evaluated with the same "weight".

[mdiep]

Semver specifies that a prerelease is "a hyphen and a series of dot separated identifiers immediately following the patch version". So 3.0.0.alpha.1 isn't a valid semver tag and it shouldn't be treating it like one. But there are some inconsistencies today in Carthage with how those types of tags are treated.

[tonyarnold]

Thanks @mdiep - it's definitely an issue with the tag. Perhaps Carthage should just ignore non-SemVer compatible tags for resolution?

[mdiep]

Yes. Carthage should ignore those tags unless they're explicitly specified.

[jdhealy]

Yes. Carthage should ignore those tags unless they're explicitly specified.

As clarification, @mdiep only proposes changing the behavior in his comment — at no point (as of my comment) has the ignoring of those tags been Carthage’s behavior.

Watch this issue and referenced PR for any potential future work.

[mdiep]

An interested party could start by adding a pending test to ResolverSpec!

[ikesyo]

Is this addressed by #2412?

[mdiep]

Only partly. If you have a tag that's not a semantic version (e.g. foo), you'll still hit this.