On Mon, 14 Apr 2014 20:32:50 GMT, Joseph Rushton Wakeling wrote:
On Mon, 14 Apr 2014 22:10:02 +0200, Sönke Ludwig wrote:
At this point I'm convinced that always using versions is the way to go.
Just tagging a new v0.0.x or something similar after a couple of days or
after each feature/important bug fix is trivial and helps a lot to at
least let any dependent libraries be stable as long as they target a
specific version.Just to make sure I understand, how is this meant to work in terms of what's in package.json, what is tagged on the master branch (do there need to be git tags?), and what should be done with the version indicators in package.json in the development branch in-between version releases?
Regarding the tags, yes there always need to be version tags. It doesn't matter on which branch(es) they are on, though. For example the libgit2 binding only has source code in secondary branches.
For development branches, you'd usually use a pre-release version, such as 2.0.0-dev.1, 2.0.0-pre.1, 2.0.0-alpha.1 or similar. For the initial development, all the 0.x.y versions can be freely used without having to regard the usual backwards compatibility requirements.
I usually kind of like the even-odd version scheme, where even minor numbers mean stable versions and odd numbers mean development, but unfortunately SemVer forbids this kind of use (and, to be frank, makes versions a lot more useful by doing that).