-
Notifications
You must be signed in to change notification settings - Fork 19
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
Bump Cabal to < 3.13, add Haskell CI for GHC 8.0 - 9.10.0 #30
Conversation
@@ -1,5 +1,6 @@ | |||
name: ghc-paths | |||
version: 0.1.0.12 | |||
x-revision: 6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@andreasabel did you add this line by accident?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't remember, but usually I do it by intention.
I just checked, the currently published revision is 6 and in sync with the .cabal file in the repo, except that the hackage-published one does not have the tested-with
field.
The preferred way, imo, to do revisions is from the repo via hackage-cli
, so the x-revision
field should be up to date in the repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue with this approach is that once you bump the version
, you need to remove the x-revision
. That means you have an informal dependency between those fields, where when you modify one you also have to modify the other. The obvious disadvantage is that you could forget to do so. That's the reason why I would avoid such dependencies when possible.
Also, it's not uncommon to modify multiple cabal files for a package at the same time. I think this workflow just wouldn't work then. And also it's common for Hackage trustees to publish revisions. Here the idea that the x-revision
should be reflected upstream certainly falls apart.
But, if this workflow works for you then that's fine with me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One way to look at it is to consider x-revision
as an extension of version
, so, yes, as you say, one has always to look at both of them.
If others made revisions on Hackage, there is hackage-cli sync-cabal
to pull the changes in.
But on the other hand, making a revision should come with evidence that the revision is sound.
Usually I deliver such evidence by a successful CI run with the relaxed bounds.
This means that the revision needs also be tracked in the home repo.
I think it is overall cleanest if one first does the revision in the home repo, certifies it through successful CI, and then pushes the revision up to hackage with hackage-cli push-cabal
.
This is the work I follow (when possible) and I would put up to competition.
CI runs here: andreasabel#1
GHC 9.10 fails because of:
setup.Cabal < 3.12
? haskell/cabal#9917