Closed slindberg closed 8 years ago
@mmun This is implemented as you describe in your comment on #20, with the exception that I did not include a --prepatch
option since it's redundant and uncommon.
Ultimately I decided that the situation I described is not a big deal, and certainly not worth holding back support for prereleases any longer.
Sweet! Looks great.
:+1: - LGTM
As an aside (this is unrelated to logic in this repo), it does seem slightly odd to me that ember release --premajor beta
or ember release --prerelease
starts at 0 (instead of 1). Again, doesn't matter much, just surprised me that that was the semver packages incr result.
@rwjblue that surprised me too, but only because I was used to the Ember convention of starting at 1. Do you know where that came from? It looks like it goes all the way back to the 1.0.0-pre
days.
I debated changing it to start at 1 for consistency, because after all this addon is part of an opinionated framework that already seems to have an opinion on the subject. The downside is it's not vanilla SemVer, although it's such a minor thing that I can't imagine it really throwing off someone new to Ember.
Thoughts?
I'm 100% happy to follow the semver package here. It's pretty trivial to just specify the next version on the command line (likely what I would do anyways vs looking up the right --presomething command).
TBH, I'm not sure where our convention of starting with beta.1 came from, but I vaguely feel like most non-ember related packages that I've seen do the same (could just be my own internal confirmation bias though).
SGTM.
@rwjblue I totally agree. Some of the semver
default behaviours are not intuitive.
In particular I don't like that --prerelease
has two behaviours: (A) if you are in a prerelease version already, increment the release version (e.g. from 1.2.3-beta.1
→ 1.2.3-beta.2
). or (B) otherwise, do a --prepatch
. The (B) case is extremely unintuitive to me. I'd argue that it should just throw in that case.
Closes #20