Update Package.swift to use NIOHTTP2's nghttp2-support-branch.
#393
Conversation
| "branch": null, | ||
| "revision": "88bd6d369a729f88e63f53ae5265840de4bb1384", | ||
| "version": "0.2.1" | ||
| "branch": "nghttp2-support-branch", |
There was a problem hiding this comment.
@Lukasa we should probably make a new release here
There was a problem hiding this comment.
Makes sense; given that that branch will only receive minor patches in the future, I think it would make sense to depend directly on the branch regardless?
There was a problem hiding this comment.
@MrMage I think that you cannot tag versions if you depend on anything by .branch(...).
There was a problem hiding this comment.
@weissi sorry, what do you mean with that?
There was a problem hiding this comment.
@MrMage IIRC, if you have a package foo that depends on another package bar using .branch("some-bar-branch"), then foo can never have a tagged version.
IIRC the failure happens if I build an executable package my-exec that depends on foo with some version (say from: "1.0.1") and the tagged 1.0.1 version depends on bar using .branch("some-bar-branch"), then my-exec won't compile.
There was a problem hiding this comment.
@MrMage the other way around works, yes. But what I described above does really not work, @aciidb0mb3r will know for sure and I think @tanner0101 does too?
There was a problem hiding this comment.
@MrMage I think the idea is that SemVer-wise it doesn't make sense to claim that you have a certain version if you're not restricting your dependency at all
There was a problem hiding this comment.
Thanks for the elaboration! In that case, we can probably drop this PR and have you guys tag 0.2.2 instead.
There was a problem hiding this comment.
@MrMage let's wait for @aciidb0mb3r or @tannner0101 to confirm, they know better
There was a problem hiding this comment.
I'm not sure whether or not you can do that, but you definitely shouldn't.
|
Obsolete. |
No description provided.