-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
feat: PVP Version implementation for the Stack build tool (Haskell) #13224
Conversation
Co-authored-by: JasonMFry <[email protected]>
Co-authored-by: JasonMFry <[email protected]>
Your git version is outdated, you need to update or use one of our docker images to run tests |
lib/versioning/pvp/index.ts
Outdated
export const supportsRanges = true; | ||
|
||
// https://pvp.haskell.org/#version-numbers | ||
type PVP = { |
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.
You should use our generic versioning class as base for this, as it will provide most of your implemention.
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.
Hi, thanks for reviewing! Could you point out the generic versioning class? When I look at the other implementations I don't see any of them using a generic versioning class.
Ruby for instance takes a similar approach:
interface RubyVersion {
major: number;
minor: number;
patch: number;
prerelease: string[] | null;
}
Other ones seem to use the npm implementation if they use semver or pep440.
helm:
export const api: VersioningApi = {
...npm,
}
rez:
function getMajor(version: string): number {
try {
return npm.getMajor(padZeroes(version));
} catch (err) /* istanbul ignore next */ {
return pep440.getMajor(version);
}
Note those other implementations would be incompatible with PVP.
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.
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.
yes, this:
renovate/lib/versioning/loose/generic.ts
Line 131 in 68dfc27
export abstract class GenericVersioningApi< |
the stuff before is obsolete and will be removed soon
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.
Thanks for pointing that out. I'll try to refactor with that class now. That file also seems to calify our questions on ranges:
renovate/lib/versioning/loose/generic.ts
Lines 18 to 20 in ee79cf7
// since this file was meant for no range support, a range = version | |
// parse should return null if version not valid | |
// parse should return an object with property release, an array of version sections major.minor.patch |
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.
I have updated my PR to use the Generic versioning class now.
Co-authored-by: HonkingGoose <[email protected]>
lib/versioning/pvp/readme.md
Outdated
The one unusual difference between PVP and semver is that there are 2 major versions, and that | ||
there could be additional version numbers past patch. |
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 one unusual difference between PVP and semver is that there are 2 major versions, and that | |
there could be additional version numbers past patch. | |
The one unusual difference between PVP and SemVer is that there are two major versions, and that there could be additional version numbers past _patch_. |
This should go on one line (one sentence per line pattern).
SemVer is a specific term/name, so should be capitalized. 😉
Are you sure you that patch is the correct term? According to the Haskell Package Versioning Policy, c is called minor.
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.
SemVer is a specific term/name, so should be capitalized. 😉
Sorry I have terrible grammar. Thanks for the suggestions!
Are you sure you that patch is the correct term? According to the Haskell Package Versioning Policy, c is called minor.
I've updated the instructions. Let me know if that's better.
Co-authored-by: HonkingGoose <[email protected]>
Co-authored-by: HonkingGoose <[email protected]>
Co-authored-by: Michael Kriese <[email protected]> Co-authored-by: HonkingGoose <[email protected]>
${'3.0.0.beta'} | ${false} | ||
${'5.1.2-+'} | ${false} | ||
`('isVersion("$input") === $expected', ({ input, expected }) => { | ||
const res = !!pvp.isVersion(input); |
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.
See above
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.
☝️
|
||
/** | ||
* Compare similar to GenericVersioningApi._compare implementation | ||
* except 2.1.1.0 and 2.1.1 are not equivalent instead 2.1.1.0 > 2.1.1 |
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.
Isn't this now fixed in base class, so we can remove this overload?
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.
☝️
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.
We can probably use h2
's here, this also creates "anchors/links", that you can use to link to a specific section of this document.
Co-authored-by: Michael Kriese <[email protected]> Co-authored-by: HonkingGoose <[email protected]>
Quotes from the [Haskell PVP Specification](https://pvp.haskell.org/): | ||
|
||
> A package version number **SHOULD** have the form A.B.C, and **MAY** optionally have any number of additional components, for example 2.1.0.4 (in this case, A=2, B=1, C=0). | ||
> A.B is known as the _major_ version number, and C the _minor_ version number. |
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.
> A.B is known as the _major_ version number, and C the _minor_ version number. | |
> A.B is known as the _major_ version number, and C the _minor_ version number. |
These are separate quotes in the upstream docs, so we should put a newline between them.
> A package version number **SHOULD** have the form A.B.C, and **MAY** optionally have any number of additional components, for example 2.1.0.4 (in this case, A=2, B=1, C=0). | ||
> A.B is known as the _major_ version number, and C the _minor_ version number. | ||
|
||
The one unusual difference between PVP and SemVer is that there are two major versions, and that there can be an optional number of additional version numbers past _minor_. |
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 one unusual difference between PVP and SemVer is that there are two major versions, and that there can be an optional number of additional version numbers past _minor_. | |
The main differences between PVP and SemVer: | |
- PVP allows _two_ major versions | |
- PVP allows an optional number of extra version numbers past _minor_ |
> A.B is known as the _major_ version number, and C the _minor_ version number. | ||
|
||
The one unusual difference between PVP and SemVer is that there are two major versions, and that there can be an optional number of additional version numbers past _minor_. | ||
For example `1.2.3` (note there's no _patch_ version here), `1.2.3.4` (`4` is the _patch_ version), or `1.2.3.4.5.6.7` are all valid version numbers. |
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.
For example `1.2.3` (note there's no _patch_ version here), `1.2.3.4` (`4` is the _patch_ version), or `1.2.3.4.5.6.7` are all valid version numbers. | |
| PVP version | Note | | |
| --- | --- | | |
| `1.2.3` | No _patch_ version | | |
| `1.2.3.4` | `4` is the _patch_ version | | |
| `1.2.3.4.5.6.7` | This is also a valid version | |
We can try a table here. You'll need to run yarn prettier-fix
after applying the suggestion because it's not formatted the way Prettier wants.
|
||
## Are ranges supported? | ||
|
||
Currently this is not supported but you can have ranges. |
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 h2
asks: Are ranges supported?
And our answer is: this is not supported
, but right after: but you can have ranges
.
This is really confusing me. I think there's some kind of difference between Cabal and Stack?
## Are ranges supported? | ||
|
||
Currently this is not supported but you can have ranges. | ||
This implementation just supports updating extra-deps in the Stack build tool which does not support ranges. |
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.
This implementation just supports updating extra-deps in the Stack build tool which does not support ranges. | |
Our implementation supports updating extra-deps in the Stack build tool which does not support ranges. |
We can probably say "our implementation" and get rid of the word "just". 😉
|
||
Currently this is not supported but you can have ranges. | ||
This implementation just supports updating extra-deps in the Stack build tool which does not support ranges. | ||
If this is used for Cabal then it would be useful to support ranges. |
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.
This sentence doesn't really explain if I can use ranges with Cabal or not currently?
${'renovatebot/renovate#main'} | ${false} | ||
${'https://github.com/renovatebot/renovate.git'} | ${false} | ||
`('isValid("$version") === $isValid', ({ version, isValid }) => { | ||
const res = pvp.isValid(version); |
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.
please inline
${'3.0.0.beta'} | ${false} | ||
${'5.1.2-+'} | ${false} | ||
`('isVersion("$input") === $expected', ({ input, expected }) => { | ||
const res = !!pvp.isVersion(input); |
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.
☝️
return { release: [major, ...rest] }; | ||
} | ||
|
||
override getMajor(version: string): number | null { |
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.
why you need to override this?
|
||
/** | ||
* Compare similar to GenericVersioningApi._compare implementation | ||
* except 2.1.1.0 and 2.1.1 are not equivalent instead 2.1.1.0 > 2.1.1 |
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.
☝️
Closing due to staleness |
Updates
Changes:
lib/versioning/
Context:
This adds a PVP implementation that can be used to integrate Stack support for Renovate.
@rarkins suggested approaching the implementation in 4 parts.
See this issue: #8187
Caribou uses Renovate and it's been great for our typescript repos, and it's been great. So thanks for creating this product! We would love to have support for our Haskell repos, and it would be great for the Haskell community in general.
TODOs
In the original issue they mention we only need to handle specific versions and not ranges, and that would also make the implementation easier. However, given that we were unsure how to implement some of the range-related functions.
How would do we run the tests?
I attempted
npm run test
but I get the following error:Documentation (please check one with an [x])
How I've tested my work (please tick one)
I have verified these changes via: