-
-
Notifications
You must be signed in to change notification settings - Fork 265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pkg.Types.semver_spec intersects version specs wrong #751
Comments
Looks correct to me since
is the union of
and
? |
I wasn't aware that this would be done via a union - I was under the impression that there was an intersection, since this
intersects to |
I'm still not seeing where you're getting the expectation of intersection from: julia> Pkg.Types.semver_spec(">=0.7")
VersionSpec("0.7.0-*")
julia> Pkg.Types.semver_spec("^1")
VersionSpec("1.0.0-1")
julia> Pkg.Types.semver_spec(">=0.7, ^1")
VersionSpec("0.7.0-*") The |
Yes, I understand that it's a union - all I'm saying is that I don't see a way to express Further, the doc actually says it's an intersection, not a union:
(Emphasis mine). |
Since there will not be a v0.8 release of Julia you can use
This was corrected in #773 |
Well, of course I can use that for this one special case.. What I'm saying though is that, in general, it's not possible to currently provide a version spec specifying support from version x.y.z up to but not including (x+1).0.0 because of that union - which would be useful, since that's when major breakage is expected to happen, whereas minor or patch releases are not generally expected to break code. In terms of the package referenced in the OP, I don't expect the Logging interface to change before 2.0 in a major way - so how do I express that I do expect it to change with 2.0, since that code is only semi-reliably exported now? |
Wouldn't This behavior of the comma does seem to be at odds with what Cargo does: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#multiple-requirements This is completely unspecified except for the vague sentence:
Which, of course, doesn't tell you anything really—is it a union or an intersection? However, the example suggests that in Cargo it's an intersection since if it's a union then the example allows any version at all, whereas if it's an intersection, then it's a sensible constraint of npm uses |
No, that's precisely what I mean - but how can I specify that in e.g. Project.toml? I have to use the comma seperated list there, and the union prevents me from solving this easily without having to write all possibly existing future minor versions before the next major version. |
Why can't you can write |
|
@StefanKarpinski Because that's an invalid version specifier. A modified Project.toml for a newly generated Package with that specifier:
which gives the following Error when trying do
@fredrikekre yes, that would work for only having one major version jump - but this quickly becomes longer with multiple jumps, or in the case of |
There's two issues here:
I'm much more concerned about 1 than 2—largely because if syntax matches Cargo and is expressive enough for Cargo, then I think it's unlikely that it's insufficiently expressive for us. Regarding 2, however, @Seelengrab can you please describe the set of versions you want to express as an open/closed interval with fully specified point version endpoints? |
I want to specify in the particular case of IOLogging.jl the compatible version range as How Cargo and npm handle this, I do not know. I suspect both intersection and union are needed for the general case though. |
Ah, well. It shouldn't be. It should be a valid version specifier for the version range |
I asked for fully specified patch version endpoints. This is ambiguous. Do you mean |
I edited my response - but I'm not sure which one is right. I basically want to support any version greater than or equal to |
Ok, I understand what you're saying now. Thanks for clarifying. |
So, as the current implementation you basically need one specifier per "breaking version" which is a minor bump pre v1 and a major bump post v1. I think that makes sense. So for the current state of Julia releases, if you want to support Julia v0.7.X and 1.X you need (and should) use something like |
Does no one care that our syntax is completely different from Cargo? @KristofferC, I assume that was not the intention and that this was a mistake due to the poor specification of the Cargo docs? |
I'm reopening this because I think it was unintentional to diverge from Cargo's behavior. |
As Fredrik says, the way it is right now, you just list what potentially breaking versions you are compatible with. With no more 0 major versions being released for Julia this will in practice you would have to list for example |
So it seems the divergence from Cargo is intended. I have to say, it makes sense to me to just list the major and/or minor versions that you're known to be compatible with. It would be nice to support hyphen range syntax in these too so that |
Adding things to Lines 340 to 345 in dfb341a
|
Ok, I'll close this and make that a feature request issue instead. |
Shouldn't this give
VersionSpec("0.7.0-0.*")
?EDIT: the rest was a seperate issue covered here.
Ref. this discussion on discourse and this Issue in METADATA.jl.
The text was updated successfully, but these errors were encountered: