Support GHC range from 9.0.2 to 9.12.2 #54
Conversation
| @@ -1,5 +1,5 @@ | |||
| name: strong-path | |||
| version: 1.1.4.0 | |||
| version: 1.2.0.0 | |||
There was a problem hiding this comment.
We're updating the lower bounds for some libraries, so this is a breaking change. We're dropping support for GHC 8.10.7, which was a big one.
There was a problem hiding this comment.
This file is autogenerated.
package.yaml
Outdated
| - tasty-quickcheck >=0.10 && <0.11 | ||
| - tasty-discover >=4.2 && <4.3 | ||
| - hspec >=2.7 && <2.10 | ||
| - hashable |
There was a problem hiding this comment.
Hashable is already covered in the library target.
There was a problem hiding this comment.
Ok! What did we say about possibly wanting to be explicit about version numbers though? Not yet/here?
There was a problem hiding this comment.
Looks like the convention is to specify common dependencies in the top-level dependencies section. So that's what I did in the end.
sodic
changed the title
sodic
changed the title
| # Also, make sure to adjust tested-with field in package.yaml so that it contains | ||
| # corresponding GHC version. | ||
| stack-resolver: lts-18.21 | ||
| stack-resolver: lts-19.33 |
There was a problem hiding this comment.
Lower bound for testing, corresponds to GHC 9.0.2., three years old.
This ensures that there are no GHC versions that don't have an appropriate StrongPath version.
In other words, there's no "gap" in supported GHC versions. Whichever version of GHC you are using, there's a Strong Path version for you:
- Up to 9.0.1 - Strong Path 1.1.4.0
- After 9.0.2 - Strong path 1.2.0.0
There was a problem hiding this comment.
I didn't quite get the second part of the message (everything beyond first sentence), could you explain in simpler way?
There was a problem hiding this comment.
The sentence was non-sensical due to edits, so no wonder you couldn't understand it.
Edited :)
package.yaml
Outdated
| - filepath >=1.4 && <1.6 | ||
| - template-haskell >=2.17 && <2.24 | ||
| - hashable >=1.3 && < 1.6 |
There was a problem hiding this comment.
For all dependencies:
- Lower bounds match GHC 9.0.2 (Stack's LTS 19.33). I matched only the first two digits, ignoring minors. That's how we've done it so far.
- Upper bounds match GHC 9.12.2 (Stack's nightly-2025-10-29). I set the exclusive upper limit to the next breaking change version.
For example:
LTS 19.33has the version offilepathset to1.4.2.2nighly-2025-10-29says has a version offilepathset to1.5.4.0- Strong path requires
filepath >=1.4 && <1.6
I went through the breaking changes version of all libraries I bumped and didn't see antyhing that should affect us. CI tests should confirm this.
Previous discussion here: #53 (comment)
There was a problem hiding this comment.
Great! Would it make sense to document this, either here in package.yaml, or in README.md, for future updates?
| # Also, make sure to adjust tested-with field in package.yaml so that it contains | ||
| # corresponding GHC version. | ||
| stack-resolver: lts-18.21 | ||
| stack-resolver: lts-19.33 |
There was a problem hiding this comment.
I didn't quite get the second part of the message (everything beyond first sentence), could you explain in simpler way?
package.yaml
Outdated
| - filepath >=1.4 && <1.6 | ||
| - template-haskell >=2.17 && <2.24 | ||
| - hashable >=1.3 && < 1.6 |
There was a problem hiding this comment.
Great! Would it make sense to document this, either here in package.yaml, or in README.md, for future updates?
package.yaml
Outdated
| - tasty-quickcheck >=0.10 && <0.11 | ||
| - tasty-discover >=4.2 && <4.3 | ||
| - hspec >=2.7 && <2.10 | ||
| - hashable |
There was a problem hiding this comment.
Ok! What did we say about possibly wanting to be explicit about version numbers though? Not yet/here?
test/Test/Utils.hs
Outdated
| convertPosixPath :: FilePath -> Char -> FilePath -> FilePath | ||
| convertPosixPath rootReplacement separator posixFp = | ||
| case posixFp of | ||
| "" -> "" | ||
| '/' : rest -> rootReplacement ++ map convertSeparator rest | ||
| _ -> map convertSeparator posixFp |
There was a problem hiding this comment.
| convertPosixPath :: FilePath -> Char -> FilePath -> FilePath | |
| convertPosixPath rootReplacement separator posixFp = | |
| case posixFp of | |
| "" -> "" | |
| '/' : rest -> rootReplacement ++ map convertSeparator rest | |
| _ -> map convertSeparator posixFp | |
| convertPosixFp :: FilePath -> Char -> FilePath -> FilePath | |
| convertPosixFp newRoot newSeparator posixFp = | |
| case posixFp of | |
| "" -> error "Empty string is not a valid posix path." | |
| '/' : restOfAbsPosixFp -> newRoot ++ map convertSeparator restOfAbsPosixFp | |
| relPosixFp -> map convertSeparator relPosixFp | |
| where convertSeparator c = if c == '/' then newSeparator else c |
- Renaming to
convertPosixFp->Fpmakes it aligned with how we name other functions. I was also tempted to name it more similar toposixToSystemFpandposixToWindowsFp, somethig likeposixToSomeFporposixToSpecificFp, but wasn't convinced enough. - I renamed
separatorto conceptually bind it torootReplacement, they are both replacements, so that shoudl be clear. I did also renamereplacementtonewin the process as I think it is at least equally clear but simpler. - I named variables, including
_, a bit richer, so it is clearer what the intention was.
There was a problem hiding this comment.
Good suggestions, I applied all of them.
No description provided.