semver ability like npm

[calvinmetcalf]

the npm version command is a nifty feature, it might be nice for tin to be able to increment versions like that, if they conflict it can just default to the highest one.

[jprichardson]

Good idea. Thanks!

[jprichardson]

OK, I get that major => x.0.0, minor => 0.x.0, and patch => 0.0.x. But what's build?

[calvinmetcalf]

so 1.1.1-string.1 (with string being anything e.g. alpha, build. dev) is less then 1.1.1 I believe build increments the last number there.

That's the released identifier, build i is a plus sign following the number, examples from the spec: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85

[stephenmathieson]

what about tin inc {release} where release is major, minor or patch?

tin could then:

var semver = require('semver')

var version = require('./{package,component,bower}.json').version
var updated = semver.inc(version, release)

so tin inc patch would bump the patch, tin inc major would bump the major, etc.

[jprichardson]

@stephenmathieson I like it. Except I think I'll stick with the version like NPM. So if it's not a number string e.g. 1.0.1, it would expect major, minor, patch. The only thing that I think is a bit confusing is that I use version with no args to return tin's version. So maybe that should be changed. Thoughts?

[stephenmathieson]

imo, this isn't a feature which justifies breaking backwards compatibility, so changing --version isn't ideal. it's your call though.

i choose inc because a version command and a --version flag would be too confusing. what about tin bump {release} instead?

[calvinmetcalf]

+1 on bump