Skip to content
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

Merged
merged 1 commit into from
Jun 8, 2024

Conversation

andreasabel
Copy link
Contributor

@andreasabel andreasabel commented Apr 27, 2024

@@ -1,5 +1,6 @@
name: ghc-paths
version: 0.1.0.12
x-revision: 6
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

@sol sol Jul 17, 2024

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.

Copy link
Contributor Author

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.

@andreasabel andreasabel deleted the ghc-9.10 branch November 13, 2024 23:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants