5 ms·

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

by 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.
- baddox 8y ago
  I’m no expert in semver, but I’m fairly confident that updates which change outputs absolutely count as breaking changes. Surely it isn’t just the signatures of public APIs that are considered to be breaking changes. It seems to me that the semver concept of “breaking changes” by definition applies to almost all changes to a code formatted like Prettier, except for updates which truly don’t affect the output of any given input (like performance improvements or support for additional platforms). Most pieces of software can have non-breaking changes like adding new features, but if you add a new feature to Prettier (like specific formatting rules for React hooks [0]), you of course change the formatted output of code that uses React hooks. https://github.com/prettier/prettier/blob/master/CHANGELOG.md#1161 https://github.com/prettier/prettier/blob/master/CHANGELOG.m...
  - CiaranMcNulty 8y ago
    It's as simple as adding to the README 'do not depend on specific output as it will change between versions' and then you're doing server...
    - baddox 8y ago
      Well, sure, you could always just lie. But in practice, Prettier updates would literally be breaking changes, as in, if you have your CI verifying that code conforms to Prettier's formatting, and you're using a new version of Prettier locally, your commits will literally break the tests. Which is, of course, what "breaking change" means in practice.
  - yawaramin 8y ago
    Looking at the actual specification ( https://semver.org/ https://semver.org/ ): > 1. Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive. I don't believe we can make such a claim about Prettier's output format. For example, how would you denote a backward-compatible change to the output format?
kumarharsh 8y ago
Since prettier isn't using Semver (I don't think it can either), maybe instead of Semver, you can experiment with alternate schemes which do provide more clarity. Example: an `YYMM.patch` style version, something like "1903.01"

by vjeux 8y ago

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.

baddox 8y ago
I’m no expert in semver, but I’m fairly confident that updates which change outputs absolutely count as breaking changes. Surely it isn’t just the signatures of public APIs that are considered to be breaking changes. It seems to me that the semver concept of “breaking changes” by definition applies to almost all changes to a code formatted like Prettier, except for updates which truly don’t affect the output of any given input (like performance improvements or support for additional platforms). Most pieces of software can have non-breaking changes like adding new features, but if you add a new feature to Prettier (like specific formatting rules for React hooks [0]), you of course change the formatted output of code that uses React hooks. https://github.com/prettier/prettier/blob/master/CHANGELOG.md#1161 https://github.com/prettier/prettier/blob/master/CHANGELOG.m...
- CiaranMcNulty 8y ago
  It's as simple as adding to the README 'do not depend on specific output as it will change between versions' and then you're doing server...
  - baddox 8y ago
    Well, sure, you could always just lie. But in practice, Prettier updates would literally be breaking changes, as in, if you have your CI verifying that code conforms to Prettier's formatting, and you're using a new version of Prettier locally, your commits will literally break the tests. Which is, of course, what "breaking change" means in practice.
- yawaramin 8y ago
  Looking at the actual specification ( https://semver.org/ https://semver.org/ ): > 1. Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive. I don't believe we can make such a claim about Prettier's output format. For example, how would you denote a backward-compatible change to the output format?

kumarharsh 8y ago

Since prettier isn't using Semver (I don't think it can either), maybe instead of Semver, you can experiment with alternate schemes which do provide more clarity. Example: an `YYMM.patch` style version, something like "1903.01"