6 ms·

The absolute most important thing they could do is add a fourth number, at the front, that is meaningless - the vanity number. vanity.major.minor.patch. There h

The absolute most important thing they could do is add a fourth number, at the front, that is meaningless - the vanity number. vanity.major.minor.patch. There has been so much wasted time, and incorrect versioning, just because people have not "felt" that breaking changes constituted "major" semver updates - just to then break many production systems due to semver ranges only working iff major, minor, and patch actually attempt to mean anything. This is a losing battle -- we are never going to convince people of this. So let's just acquiesce. Let's allow the first number to advance at whatever rate you like. It's the "human" portion of the version number. That way, everything to the right of it, no one will care about and can serve its actual purpose. Ultimately this isn't even a new idea, its just "the PR version" vs. "the build number" just like native apps have had for ages.

nerdponx 8y ago
I don't see anything wrong with something like "Angular 2 (v1.3.6-a)". It's not a new version of the same software -- it's new software.
- tolmasky 8y ago
  Just to clarify, the real concern is the opposite of what you are showing, when the semver version advances faster than the "desired" version. So for example, something like Angular 1 (v2.5.6), because it contains a change that breaks 1.x.x users. Regardless, "what's wrong" is that people just don't behave this way, and there's no way to convince them otherwise. For better or worse, semvers have taken on the dual role of "build version" and "public facing version" (probably because that's the only version users actually end up seeing out in the wild). So there is tremendous resistance to advancing the MAJOR portion of the semver faster than their "marketing" desires. I have been in many, many, frustrating arguments on GitHub where there are several users that are begging to simply release a package under a MAJOR update instead of (erroneously) under a MINOR version, because it is incredibly difficult and confusing when a subdependency of a subdependency picks up a seemingly innocuous change which is actually breaking solely because "it still felt like it belonged in this major version", and the "fix" for this on the user's end is super complex - having to dive many layers deep in the dependency tree and wrestle with a lockfile - all because the change "didn't feel 2.0 worthy". In theory, if you can prove that a change breaks current users, there should be no further discussion, the change merits a major update. But you will be surprised how all of a sudden crazy unrelated arguments start popping up. Ultimately, its all because there is an emotional attachment to the leftmost number, simple as that. Look no further than Underscore's "romantic versioning" (https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e ) drama back when SemVer was first introduced, when it was stated that it would be ridiculous for underscore to be at "version 157" or something had they followed semver to the letter. But again, its only ridiculous because people want to attach PR value to the Major version. It is absolutely not ridiculous from the perspective of knowing that there were 157 breaking changes, and 157.x.y won't work with 156.x.y.
erikpukinskis 8y ago
In the case of a non-breaking "new version" release would you go directly from, say, 1.4.6.0 to 2.4.7.0 then? And for a breaking "update" release you' go from 1.4.6.0 to 1.5.0.0?
- tolmasky 8y ago
  Yes, precisely. You could have big flashy releases with "2" branding that as far as automatic updates are concerned are non-breaking and non-conceptual (new logo! we got acquired! better docs! whatever). You can also have important bug fixes that will break existing clients and thus should not auto-update, but under the "idea" of 1.0.
  - slowmovintarget 8y ago
    That sounds awful. It makes it even harder to make decisions about whether to accept a new version because it is tangling different concerns into a single knot and saying "here, we might mean all of these things, you figure it out!" Just change the name.
    - tolmasky 8y ago
      The name doesn't show up anywhere Also, there is too much focus on the least important of the two scenarios: wanting to increase the version number with no meaningful changes. The actually important scenario is the opposite: when the major version SHOULD be upgraded but people don't want to give the impression that this is a "major release" (in the colloquial sense). This is why the name is irrelevant: this is a situation where you'd want to "keep the name the same", and we already see that not working. Perhaps you'd be happy with making the vanity portion I suggested a "name"? mojave.1.0.3? This is 100% equivalent to what I was already proposing (the vanity section is pure vanity and is meaningless in package resolution), but seems to also satisfy your concern that it would be confusing if it were a number. Does that satisfy your concerns? My concern is simple: unless he "name" shows up in config files, it will not have the power of the "major" version and will thus inevitably result in people not properly upgrading the major version when necessary.
s3cur3 8y ago
The issue with the present system is that we have one numbering scheme trying to satisfy two very different roles: - automated dependency management (“can I safely update to this version?”) - marketing (“do I care about this new version?”)
- vjeux 8y ago
  I’m running into this issue with “prettier”, a JavaScript pretty printer. If we were to follow semver, we’d have to always bump the major version because every version changes in some way or form the output of some construct. Instead what we opted to do is to have the major be 1. to signify that the project is mature, the minor for roughly quarterly big updates and the patch for hotfixes right after we ship a new update.
  - davidbanham 8y ago
    But at that point what you're doing has no resemblance to semver. And there is nothing at all wrong with that! Just don't call it semver, because if you do, people will expect it to be... y'know... semver. The same applies to putting your not-semver version number into places where people or tools expect a semver number to be placed. If you encounter those places (like npm) please put an actually-semver number in them.
    - vjeux 8y ago
      I don’t call it semver, I publish it to npm with this version number. The fact that npm install automatically adds a ^ next to the version number has caused so many issues in the past where some deep dependency would push a patch, not following semver, and break a huge part of the end users. Thankfully, yarn lockfiles were introduced and solved the problem. Only people adding the dependency for the first time would see the new behavior, which is usually fine.
  - yawaramin 8y ago
    Looking at the definition from Steve's post: > For this system to work, you first need to declare a public API. ... Once you identify your public API, you communicate changes to it with specific increments to your version number. If you don't have a public API in Prettier, SemVer doesn't actually apply. If you do have a public API, only changes to that API (meaning the types, arities, functions, names, modules etc.) qualify for version number bumps. Everything else (like changing the output format) does not qualify.
eslaught 8y ago
This is called explicit versioning [1]. But in my opinion the correct fix is the one suggested in this comment: https://news.ycombinator.com/item?id=19138143 https://news.ycombinator.com/item?id=19138143 Windows is a great example: the number behind the name (7, 8, 8.1, 10, etc.) is just marketing gobbledygook. It doesn't even have to be a number (XP, etc.). The real version number of Windows is hidden from regular users---though they don't follow semver so I'm not sure it has much value per se. But they could plausibly adopt semver and regular users wouldn't need to know. Let the marketing people choose the branding and the developers choose the version numbers. Keep those concerns separate, don't force them to be conflated. [1]: https://medium.com/sapioit/why-having-3-numbers-in-the-version-name-is-bad-92fc1f6bc73c https://medium.com/sapioit/why-having-3-numbers-in-the-versi...
- wutbrodo 8y ago
  Yea I don't get why you can't do this already, effectively. Just hide the real semver in the place it'll be consumed, with a comment tying it to the branded version if you want to reduce confusion.
  - charrondev 8y ago
    By numbers NPM is probably the biggest ecosystem using semver but the config files are JSON which don’t allow comments. Bit of a PITA generally but also makes this tougher to do consistently.
sli 8y ago
Honestly, I agree with you. A current client has been trying to dictate our version numbers purely for marketing purposes and we've been pushing back since the start of the project. They originally wanted us to release 1.0 as 1.5, literally so they could imply that the software was further along than it actually was at the time (software marketing people sure seem to love lying to their own potential clients). At least we no longer tie our sprints to version numbers (also at the behest of the client). Our scrum master eventually decoupled them unilaterally because the workload was getting ridiculous, and our internal project management was ending up as simply a formality because of it. We're all grateful for that one.
- d4rti 8y ago
  Clients don't always help themselves here though with blanket policies against deploying 1.x or x.0 releases.
kakwa_ 8y ago
Not sure if it's a good idea. A better idea in my opinion would be to have 2 versions: * an "API" version that specifies technical changes. * a public version more representative of big milestones in the project. It's roughly what is done in the C/C++ ecosystem with sonames. But I agree, that's indeed a flaw of SemVer IMHO. According SemVer, even if you are adding tons of new cool and useful features, while maintaining compatibility of existing one, you are not supposed to increase the major number. From a "social" point of view, it gives the feeling a project is not really active. And even from a technical perspective, bumping the major in case of significant changes can actually be a good idea. When I see an X.0.0 release, I kind of expect major changes inside the project, and even if the project remains compatible, significant changes generally bring bugs and instability, in some context it might be a good idea to wait for a version like X.1.4 to remain stable. With semver, 1.42.0 -> 1.43.0 can be a small add on of one method or tons of new methods. And even 1.2.2 -> 1.2.3 can be an entire rework of the internals, while the API stays exactly the same. Don't get me wrong, SemVer is great, it has enabled far less painful dependency management and better tooling, but some human and qualitative aspects are lacking in this versioning scheme.
- tolmasky 8y ago
  There's no difference between our two ideas except that I have put both "versions" together in one string (please correct me if I'm wrong here). The reason I've done this is because the second you make one version the "real" version that developers will see in their config files, that number will once again take on "emotional" value and lead to resistance to updating it. There is theoretically nothing stopping node developers from using the system you describe today -- except that the "API" version is the one that people see in their files, and so naturally becomes the "spoken" version. If the "public version" isn't represented anywhere meaningful, then it requires a tremendous amount of 1) work on the developer's part to communicate its existence, and 2) restraint to maintain the spirit of the semver that users will actually repeatedly see. This is certainly something that a big corporation like Google is capable of, but small package developers in the ecosystem have shown that they are unwilling to do. The simple hack is to just append the "public version" to the front of the "API" version, and now everyone is happy.
- 8y ago
mmphosis 8y ago
Your version number is an IP address. Among the many problems that can occur, like leaving out --ppapi-flash-version= or putting a space after it: exec /usr/bin/chromium --ppapi-flash-path=/usr/lib/adobe-flashplugin/libpepflashplayer.so --ppapi-flash-version=$(grep version /usr/lib/adobe-flashplugin/manifest.json | cut -d '"' -f 4) "$@" If it is for vanity then as another comment suggested include it in the name: python3 --version
- kam 8y ago
  1.1 and 1.1.1 are also valid IP addresses (and http://1.1 http://1.1 even works as a URL) via an obscure shorthand notation. Valid to `inet_aton()` at least, but definitely more recognizable as a version than an IP to humans.
Waterluvian 8y ago
I'm kind of convinced that this is one of those times where doing anything is worse than doing nothing. Do we really have a real problem here deserving of all the costs that come with more change?
- heyjudy 8y ago
  Exactly. Leave what works. The emperor doesn't need new clothes and we don't need the pain of fashionable, consumerist, job-security churn.
gojomo 8y ago
Great idea, but for political purposes, you might not want to call the first position 'vanity'. Perhaps 'symbolic' or 'headline'. (Or even, 'political'.)
- anth_anm 8y ago
  No, call it vanity. People deserve to be reminded that the entire thing is silly ego. Every single time.
  - kumarharsh 8y ago
    But then they'll take it on their ego, thus defeating the purpose
  - gojomo 8y ago
    Lecturing people that their preferred "leading version number" practices are "silly ego" won't help this better system attract support. But also, it's false. It's a legitimate convention, across a bunch of domains that are either analogous or intersecting with software-development, to use increments of the 1st number to signal "big user-meaningful changes" (as opposed to exactly-and-only "interface breaking changes"). It's not just ego, but evolved communication.
acranox 8y ago
> Let's allow the first number to advance at whatever rate you like This is what I feel like Pip did. https://pip.pypa.io/en/stable/news/ https://pip.pypa.io/en/stable/news/ it went from 1.5.6 to 6.0, and later from 10.0.1 to 18.0. Ok.
- jacinda 8y ago
  I don't know anything about the 1 -> 6 jump, but the jump to 18 was because they switched to time-based versioning last year (2018). First release of 2019 was 19.0.
  - acranox 8y ago
    the 1 -> 6 jump was because they decided to drop the first number. Yes, they had reasons, but changing version schemas twice in a couple years is a great way to confuse people in the interest of just doing whatever the author likes.
rmrfrmrf 8y ago
Hard disagree here. The tides are finally starting to shift on this and customers are demanding it -- no need to capitulate now.
afranchuk 8y ago
That's what Haskell has done for a while now! https://pvp.haskell.org/ https://pvp.haskell.org/
panic 8y ago
A somewhat off-the-wall solution to this problem would be to require major versions to start at some arbitrary lower limit much greater than 1. For example, imagine every semantic version started at 123.0.0. It's less of a big deal to go from version 123 to 124 than it is to go from 1 to 2.
z1mm32m4n 8y ago
I recently learned that a system like this is already described by Haskell’s Package Version Policy[1]. They call the vanity digit the “epoch”[2]. Basically the way the formalize it is that the first two components specify the major component, and a breaking change must correspond to an increment where the new major version is lexicographically greater than before. Depending on the whim of the maintainer this can be by incrementing the first or second number. [1] https://pvp.haskell.org https://pvp.haskell.org [2] https://pvp.haskell.org/faq/#semver https://pvp.haskell.org/faq/#semver

nerdponx 8y ago

I don't see anything wrong with something like "Angular 2 (v1.3.6-a)". It's not a new version of the same software -- it's new software.

tolmasky 8y ago
Just to clarify, the real concern is the opposite of what you are showing, when the semver version advances faster than the "desired" version. So for example, something like Angular 1 (v2.5.6), because it contains a change that breaks 1.x.x users. Regardless, "what's wrong" is that people just don't behave this way, and there's no way to convince them otherwise. For better or worse, semvers have taken on the dual role of "build version" and "public facing version" (probably because that's the only version users actually end up seeing out in the wild). So there is tremendous resistance to advancing the MAJOR portion of the semver faster than their "marketing" desires. I have been in many, many, frustrating arguments on GitHub where there are several users that are begging to simply release a package under a MAJOR update instead of (erroneously) under a MINOR version, because it is incredibly difficult and confusing when a subdependency of a subdependency picks up a seemingly innocuous change which is actually breaking solely because "it still felt like it belonged in this major version", and the "fix" for this on the user's end is super complex - having to dive many layers deep in the dependency tree and wrestle with a lockfile - all because the change "didn't feel 2.0 worthy". In theory, if you can prove that a change breaks current users, there should be no further discussion, the change merits a major update. But you will be surprised how all of a sudden crazy unrelated arguments start popping up. Ultimately, its all because there is an emotional attachment to the leftmost number, simple as that. Look no further than Underscore's "romantic versioning" (https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e ) drama back when SemVer was first introduced, when it was stated that it would be ridiculous for underscore to be at "version 157" or something had they followed semver to the letter. But again, its only ridiculous because people want to attach PR value to the Major version. It is absolutely not ridiculous from the perspective of knowing that there were 157 breaking changes, and 157.x.y won't work with 156.x.y.

erikpukinskis 8y ago

In the case of a non-breaking "new version" release would you go directly from, say, 1.4.6.0 to 2.4.7.0 then? And for a breaking "update" release you' go from 1.4.6.0 to 1.5.0.0?

tolmasky 8y ago
Yes, precisely. You could have big flashy releases with "2" branding that as far as automatic updates are concerned are non-breaking and non-conceptual (new logo! we got acquired! better docs! whatever). You can also have important bug fixes that will break existing clients and thus should not auto-update, but under the "idea" of 1.0.
- slowmovintarget 8y ago
  That sounds awful. It makes it even harder to make decisions about whether to accept a new version because it is tangling different concerns into a single knot and saying "here, we might mean all of these things, you figure it out!" Just change the name.
  - tolmasky 8y ago
    The name doesn't show up anywhere Also, there is too much focus on the least important of the two scenarios: wanting to increase the version number with no meaningful changes. The actually important scenario is the opposite: when the major version SHOULD be upgraded but people don't want to give the impression that this is a "major release" (in the colloquial sense). This is why the name is irrelevant: this is a situation where you'd want to "keep the name the same", and we already see that not working. Perhaps you'd be happy with making the vanity portion I suggested a "name"? mojave.1.0.3? This is 100% equivalent to what I was already proposing (the vanity section is pure vanity and is meaningless in package resolution), but seems to also satisfy your concern that it would be confusing if it were a number. Does that satisfy your concerns? My concern is simple: unless he "name" shows up in config files, it will not have the power of the "major" version and will thus inevitably result in people not properly upgrading the major version when necessary.

s3cur3 8y ago

The issue with the present system is that we have one numbering scheme trying to satisfy two very different roles: - automated dependency management (“can I safely update to this version?”) - marketing (“do I care about this new version?”)

vjeux 8y ago
I’m running into this issue with “prettier”, a JavaScript pretty printer. If we were to follow semver, we’d have to always bump the major version because every version changes in some way or form the output of some construct. Instead what we opted to do is to have the major be 1. to signify that the project is mature, the minor for roughly quarterly big updates and the patch for hotfixes right after we ship a new update.
- davidbanham 8y ago
  But at that point what you're doing has no resemblance to semver. And there is nothing at all wrong with that! Just don't call it semver, because if you do, people will expect it to be... y'know... semver. The same applies to putting your not-semver version number into places where people or tools expect a semver number to be placed. If you encounter those places (like npm) please put an actually-semver number in them.
  - vjeux 8y ago
    I don’t call it semver, I publish it to npm with this version number. The fact that npm install automatically adds a ^ next to the version number has caused so many issues in the past where some deep dependency would push a patch, not following semver, and break a huge part of the end users. Thankfully, yarn lockfiles were introduced and solved the problem. Only people adding the dependency for the first time would see the new behavior, which is usually fine.
- yawaramin 8y ago
  Looking at the definition from Steve's post: > For this system to work, you first need to declare a public API. ... Once you identify your public API, you communicate changes to it with specific increments to your version number. If you don't have a public API in Prettier, SemVer doesn't actually apply. If you do have a public API, only changes to that API (meaning the types, arities, functions, names, modules etc.) qualify for version number bumps. Everything else (like changing the output format) does not qualify.

eslaught 8y ago

This is called explicit versioning [1]. But in my opinion the correct fix is the one suggested in this comment: https://news.ycombinator.com/item?id=19138143 https://news.ycombinator.com/item?id=19138143 Windows is a great example: the number behind the name (7, 8, 8.1, 10, etc.) is just marketing gobbledygook. It doesn't even have to be a number (XP, etc.). The real version number of Windows is hidden from regular users---though they don't follow semver so I'm not sure it has much value per se. But they could plausibly adopt semver and regular users wouldn't need to know. Let the marketing people choose the branding and the developers choose the version numbers. Keep those concerns separate, don't force them to be conflated. [1]: https://medium.com/sapioit/why-having-3-numbers-in-the-version-name-is-bad-92fc1f6bc73c https://medium.com/sapioit/why-having-3-numbers-in-the-versi...

wutbrodo 8y ago
Yea I don't get why you can't do this already, effectively. Just hide the real semver in the place it'll be consumed, with a comment tying it to the branded version if you want to reduce confusion.
- charrondev 8y ago
  By numbers NPM is probably the biggest ecosystem using semver but the config files are JSON which don’t allow comments. Bit of a PITA generally but also makes this tougher to do consistently.

sli 8y ago

Honestly, I agree with you. A current client has been trying to dictate our version numbers purely for marketing purposes and we've been pushing back since the start of the project. They originally wanted us to release 1.0 as 1.5, literally so they could imply that the software was further along than it actually was at the time (software marketing people sure seem to love lying to their own potential clients). At least we no longer tie our sprints to version numbers (also at the behest of the client). Our scrum master eventually decoupled them unilaterally because the workload was getting ridiculous, and our internal project management was ending up as simply a formality because of it. We're all grateful for that one.

d4rti 8y ago
Clients don't always help themselves here though with blanket policies against deploying 1.x or x.0 releases.

kakwa_ 8y ago

Not sure if it's a good idea. A better idea in my opinion would be to have 2 versions: * an "API" version that specifies technical changes. * a public version more representative of big milestones in the project. It's roughly what is done in the C/C++ ecosystem with sonames. But I agree, that's indeed a flaw of SemVer IMHO. According SemVer, even if you are adding tons of new cool and useful features, while maintaining compatibility of existing one, you are not supposed to increase the major number. From a "social" point of view, it gives the feeling a project is not really active. And even from a technical perspective, bumping the major in case of significant changes can actually be a good idea. When I see an X.0.0 release, I kind of expect major changes inside the project, and even if the project remains compatible, significant changes generally bring bugs and instability, in some context it might be a good idea to wait for a version like X.1.4 to remain stable. With semver, 1.42.0 -> 1.43.0 can be a small add on of one method or tons of new methods. And even 1.2.2 -> 1.2.3 can be an entire rework of the internals, while the API stays exactly the same. Don't get me wrong, SemVer is great, it has enabled far less painful dependency management and better tooling, but some human and qualitative aspects are lacking in this versioning scheme.

tolmasky 8y ago
There's no difference between our two ideas except that I have put both "versions" together in one string (please correct me if I'm wrong here). The reason I've done this is because the second you make one version the "real" version that developers will see in their config files, that number will once again take on "emotional" value and lead to resistance to updating it. There is theoretically nothing stopping node developers from using the system you describe today -- except that the "API" version is the one that people see in their files, and so naturally becomes the "spoken" version. If the "public version" isn't represented anywhere meaningful, then it requires a tremendous amount of 1) work on the developer's part to communicate its existence, and 2) restraint to maintain the spirit of the semver that users will actually repeatedly see. This is certainly something that a big corporation like Google is capable of, but small package developers in the ecosystem have shown that they are unwilling to do. The simple hack is to just append the "public version" to the front of the "API" version, and now everyone is happy.
8y ago

mmphosis 8y ago

Your version number is an IP address. Among the many problems that can occur, like leaving out --ppapi-flash-version= or putting a space after it: exec /usr/bin/chromium --ppapi-flash-path=/usr/lib/adobe-flashplugin/libpepflashplayer.so --ppapi-flash-version=$(grep version /usr/lib/adobe-flashplugin/manifest.json | cut -d '"' -f 4) "$@" If it is for vanity then as another comment suggested include it in the name: python3 --version

kam 8y ago
1.1 and 1.1.1 are also valid IP addresses (and http://1.1 http://1.1 even works as a URL) via an obscure shorthand notation. Valid to `inet_aton()` at least, but definitely more recognizable as a version than an IP to humans.

Waterluvian 8y ago

I'm kind of convinced that this is one of those times where doing anything is worse than doing nothing. Do we really have a real problem here deserving of all the costs that come with more change?

heyjudy 8y ago
Exactly. Leave what works. The emperor doesn't need new clothes and we don't need the pain of fashionable, consumerist, job-security churn.

gojomo 8y ago

Great idea, but for political purposes, you might not want to call the first position 'vanity'. Perhaps 'symbolic' or 'headline'. (Or even, 'political'.)

anth_anm 8y ago
No, call it vanity. People deserve to be reminded that the entire thing is silly ego. Every single time.
- kumarharsh 8y ago
  But then they'll take it on their ego, thus defeating the purpose
- gojomo 8y ago
  Lecturing people that their preferred "leading version number" practices are "silly ego" won't help this better system attract support. But also, it's false. It's a legitimate convention, across a bunch of domains that are either analogous or intersecting with software-development, to use increments of the 1st number to signal "big user-meaningful changes" (as opposed to exactly-and-only "interface breaking changes"). It's not just ego, but evolved communication.

acranox 8y ago

> Let's allow the first number to advance at whatever rate you like This is what I feel like Pip did. https://pip.pypa.io/en/stable/news/ https://pip.pypa.io/en/stable/news/ it went from 1.5.6 to 6.0, and later from 10.0.1 to 18.0. Ok.

jacinda 8y ago
I don't know anything about the 1 -> 6 jump, but the jump to 18 was because they switched to time-based versioning last year (2018). First release of 2019 was 19.0.
- acranox 8y ago
  the 1 -> 6 jump was because they decided to drop the first number. Yes, they had reasons, but changing version schemas twice in a couple years is a great way to confuse people in the interest of just doing whatever the author likes.

rmrfrmrf 8y ago

Hard disagree here. The tides are finally starting to shift on this and customers are demanding it -- no need to capitulate now.

afranchuk 8y ago

That's what Haskell has done for a while now! https://pvp.haskell.org/ https://pvp.haskell.org/

panic 8y ago

A somewhat off-the-wall solution to this problem would be to require major versions to start at some arbitrary lower limit much greater than 1. For example, imagine every semantic version started at 123.0.0. It's less of a big deal to go from version 123 to 124 than it is to go from 1 to 2.

z1mm32m4n 8y ago

I recently learned that a system like this is already described by Haskell’s Package Version Policy[1]. They call the vanity digit the “epoch”[2]. Basically the way the formalize it is that the first two components specify the major component, and a breaking change must correspond to an increment where the new major version is lexicographically greater than before. Depending on the whim of the maintainer this can be by incrementing the first or second number. [1] https://pvp.haskell.org https://pvp.haskell.org [2] https://pvp.haskell.org/faq/#semver https://pvp.haskell.org/faq/#semver