search

jprichardson / tin

Easily manage package.json, component.json, and bower.json files.
MIT License
92 stars 4 forks source link

semver ability like npm #3

Open calvinmetcalf opened 11 years ago

calvinmetcalf commented 11 years ago

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 commented 11 years ago

Good idea. Thanks!

jprichardson commented 11 years ago

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

calvinmetcalf commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

@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 commented 11 years ago

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 commented 11 years ago

+1 on bump