I’m used to 1.0 being first release, and anything under 1.0 as alpha/beta. Why do packages have such low version numbers such as 0.1.4?
Maybe cause you can write there any number you want ?
That’s because the author does not use semver spec or not released properly at this moment.
In meteor there is no technical difference between 0.x, 1.x, 2.x and so on. (Correct me if i’m wrong)
It just makes sense for most packages to start as 0.x.x since that correctly conveys that this thing is in super early development and all kinds of things are probably going to change and move about. Those early version numbers are more of an indication of “something here has changed”, not necessarily what has changed (major vs minor vs patch number), since there is no need to concern oneself with API stability yet.
In the “real world”, i.e. if you’re managing versioning properly, version 1.0 would imply some kind of stability guarantee, both of API and of the product itself. In the early lifecycle of a project/product that simply does not make sense.
I think that most Meteor packages that do evolve beyond the initial stages do also eventually pick up proper versioning and relase version 1.0 and take it from there.
But for many small utility packages that’s simply not necessary and would represent more overhead than anything, while not making them any less “stable” (they’re often “done” with development; their scope wasn’t a very large one to begin with) or any less useful (they just work).
Hope that sheds some light on a potential perspective on versioning in the Meteor ecosystem.
(Though of course remember that this is just my perspective, and it’s relative to what I’ve seen, and what I’ve done myself.)
Edit: And just to add another note – releasing the very first version as “1.0” might have been regarded a good idea a long time ago, at least by many of us, but this has changed significantly. These days most everyone understands the importance of getting the first “release” out as early as possible, get lots of feedback and do a number of iterations on API and internals before even thinking about calling it anything close to “1.0”. Sure, if you’ve been developing a bunch of code for a while and have been using it internally for a long time and the code is well implemented and its API is nice and useful and stable and very appropriate, then yes, you could release that first public version as “1.0”. But then you’re just hiding the project’s existing history of development and use and (potentially) lots of earlier releases, which is what actually allowed it to now be released as “1.0”.
In any other case calling the first version “1.0” is most likely a terrible idea and you’re much better off leaving time and space for freely iterating on the concepts and implementations and calling it “0.x” until things settle down and become naturally (more) stable.
4 Likes
Meteor uses semver for versioning and in the semver FAQ it states:
How should I deal with revisions in the 0.y.z initial development phase?
The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.
Source: http://semver.org/
Thanks for the info!
So if I start at package at 0.1.0, when will it reach 1.0.0? According to semver, a major revision is for compatibility-breaking changes. If the API for my package always stays the same, that means I’d never hit 1.0.0.
FAQ says:
How do I know when to release 1.0.0?
If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.
So, generally if you consider your package to be production-ready at any point then you should bump it up to 1.0.0. If it’s stable already upon release to public it should be released as 1.0.0.
That’s what I figured. Good thing I released my package at 1.0.0 then, since it’s production ready 
1 Like
It’s not like anyone would prohibit you from bumping a version < 1.0 to 1.0 even if you did not bring any breaking changes along. Hardly anyone would complain about a non-breaking upgrade in major versions. It’s a bit like a free lunch… “what, I can upgrade the major version of this dependency without having to adjust anything? More of that, please!”
True, SemVer wouldn’t require you to bump your major version for no reason, but it is (more or less) indifferent about you doing so just because you want to, because it signifies something else (here: stability, production-readiness). At least that’s my understanding of it. The idea of SemVer (and sound versioning in general) is to signal (potential) API breakage / API stability, as its first priority. Anything else is secondary. And so as long as you don’t break the primary convention you’re pretty much free to do as you please.
But of course it’s also great if you already chose 1.x and it turns out to be just the right choice!
1 Like