2

When creating a new node.js project, the following is run first:

npm init

And there is a series of questions that will help initialize the package.json file. One of those questions is about version.

The version number that is supplied as an answer should strictly follow the semver standard. Now, what if I would like to use a different versioning standard that does not adhere to semver? How to enforce using different version standard? Can I also supply the new rules for the new standard to be used instead of semver to enforce the new versioning standard?

Thanks.

Greeso
  • 7,544
  • 9
  • 51
  • 77
  • Specifically what versioning scheme do you want to use? – jwdonahue Jan 09 '18 at 04:30
  • @jwdonahue - It is an "in house" versioning scheme that we device, basically chronological scheme. – Greeso Jan 09 '18 at 15:07
  • Will your packages will never be released into the wild? – jwdonahue Jan 10 '18 at 04:14
  • @jwdonahue - It will be released. But again, it is a chronological versioning. Lots of software products use it, such as Ubuntu. – Greeso Jan 10 '18 at 06:09
  • Does Ubuntu use npm to distribute their packages? Using a different version scheme in the npm echo system would break all the package dependency rules. It's a very bad idea. – jwdonahue Jan 10 '18 at 22:23
  • Exactly what does this "chronological" version scheme look like? Is it just a single monotonic number? – jwdonahue Jan 10 '18 at 22:26
  • @jwdonahue - It can take any form. It could be 18.01 (if you want to release in January 2018). or 2018.01 (same thing, another format). There are other chronological forms, but this should give you an idea. – Greeso Jan 11 '18 at 00:13

1 Answers1

4

You should never violate the contracts that are inherent in using a particular packaging/distribution tool. In this case, npm require SemVer because it provides a useful communications channel between publishers and consumers that is easily automated. Since your versioning scheme makes no distinction between bug fixes, new features and breaking changes, the best that you can do is apply a mapping from it onto SemVer, if you must use npm as your packaging scheme. There's two ways I can think of to accomplish this.

  1. Use 0.0.1 for all versions and append a -prerelease that contains your actual sequential version. These will sort as you expect them to do provided each of the dotted prerelease fields is pure numeric and they will always be legal in terms of semantic versioning.
  2. User 0.0.X, where X is the most significant field of your versioning scheme and you place the remaining values in the -prerelease tag as pure numeric doted fields.

Either of these schemes is legal SemVer and announces to all consumers that any new version is potentially a breaking change. The 0.0 prefix in SemVer essentially means all bets are off. This way, consumers willing to accept risk can automatically update to your latest version and those who are unwilling to accept such risks can avoid them.

Examples based on your comments:

0.0.1-2018.01
0.0.1-2018.02
0.0.1-2019.03

0.0.2018-01
0.0.2018-02
0.0.2019-03

After providing examples above, I personally prefer the second variation over the first one, but as far as the SemVer rules are concerned, they are literally equal.

jwdonahue
  • 6,199
  • 2
  • 21
  • 43