> It's kind of required By whom?
The instructions you link to say "Version must be parseable by node-semver". My 0.x releases were parseable by semver. Also those instructions use the example "0.1.2-7 > 0.1.2-7-beta". So forgive me if I didn't know there were rules forbidding 0.x versions in npm. Instead of telling us what to do, you could have just suggested that we follow the semver philosophy at the semver link. Cajoling works better than preaching. Unfortunately I think your suggestion will fall on deaf ears. I myself, and I suspect most others on this list, have used the old standard 0.x for many years and would be hard-pressed to change. On Thu, Sep 20, 2012 at 12:40 AM, Austin William Wright < [email protected]> wrote: > > It's kind of required if you're releasing a package using npm: https://npmjs.org/doc/json.html > > On Wednesday, September 19, 2012 11:09:56 PM UTC-7, Mark Hahn wrote: >> >> > Who else has encountered problems with packages breaking the semantic versioning scheme >> >> Not me. I didn't know any of my packages were using this scheme. Is it widely adopted? >> >> >> On Wed, Sep 19, 2012 at 6:43 PM, Austin William Wright < [email protected]> wrote: >>> >>> I've noticed that quite a lot of Node.js packages are tagging version number zero for all their releases: 0.4.0, 0.9.9, 0.0.1, 0.27.4, etc (to pick from packages that I use). It's as if people think that if the program is not fully feature-complete, they shouldn't release version 1.0.0. >>> >>> You need not feel this way! Semver <http://semver.org/spec/v1.0.0.html> exists so that, in addition to providing a unique ID for each release, we can infer some basic facts about the compatibility of the release, in comparison to other releases. It doesn't mean your code has all the features you want, it doesn't mean it has any standard of quality, it doesn't even mean "beta" or "production-ready". All semver asks you to do is (1) tell us when you break reverse-compatibility of your public API, (2) tell us when you release a new feature, and (3) tell us when you patch a particular bug. If you use major version zero, we lose all of this information. By definition, major version zero carries no semantics whatsoever. ~0 (major version zero) is supposed to be used for internal development and quick iteration where nearly every change breaks of the public API. However, if you're releasing software publicly, your users expect some stability in your public API. The series of releases that are stable against one another should carry the same nonzero major revision number, like "1.x.x". If you accidentally make a change that breaks, then just release a bugfix release for the breakage, and optionally release a new major version that carries the breakage. >>> >>> If you don't identify when you break your public API, then developers have to manually figure out which releases are breaking, and which are safe to upgrade to. We may have to carefully examine changelogs and create and run unit tests. This wastes developer time. It's also makes it hard to future-proof releases: If I know that 1.0.0 is compatible with my application, then so should 1.3.1, and any ~1 version. Unit tests are not a replacement for the major version number: When picking an appropriate package version to update to, developers (or automated programs) do not have access to changelogs or the source code to run unit tests on (nor should they). (There's also the corollary, version numbers are not a replacement for unit tests, of course.) Nor can per-module or per-function version numbers replace a package-wide version number. These sub-versions may be a good idea, but they do not tell us anything about which version of a package, something installed as a coherent whole, should be installed. >>> >>> Node.js itself is still releasing major version zero. This is unacceptable for all the same reasons. Node.js should be releasing 1.0.0 right now (and actually, a long while ago). Then, when a new feature is added (major change of an internal library, new core library, etc), increment the minor version number. If it breaks reverse-compatibility (crypto finally starts using buffers, say), increment the major revision number. It might be a minor breakage, in which case we can run all our tests and ensure it's no change that breaks the program, and then we can say "My program is compatible with Node.js ~2 as well as ~1.2". There is nothing so special about any feature like libuv that its release can't be marked with 2.0.0 instead, it's just a number that tells us something broke. It doesn't mean it's conforming to any release schedule, it doesn't mean it's feature complete. >>> >>> Having "stable" and "unstable" branches is fine for Git development, however having stable/unstable version numbers is not: The stable branch should get it's own major version number. Unstable branches would be release candidates for the next major version number: 4.0.0-a1, 4.0.0-a4, 4.0.0-rc1, etc. (Of course this numbering scheme should be avoided in production for all the same reasons, it doesn't mean anything, it's just a period of rapid iteration and API breakage.) >>> >>> It's just a number, numbers are cheap. If you need to make a dozen consecutive, breaking releases, then simply number them accordingly, 3.0.0 through 14.0.0. That's how semver works! >>> >>> Who else has encountered problems with packages breaking the semantic versioning scheme and reverse compatibility? >>> >>> Austin Wright. >>> >>> -- >>> Job Board: http://jobs.nodejs.org/ >>> Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >>> You received this message because you are subscribed to the Google >>> Groups "nodejs" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/nodejs?hl=en?hl=en >> >> > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
