jasonkarns commented 8 years ago

@tpope I've wrapped up the PRs I had slated (mostly pulling stuff from nodenv-aliases and stuff from rbenv, but also a bug fix and feature #8)

Starting further back:

155dc4404a2eac0a134d6357ad2d0b7ea302e302 (#11) was trivial feature, not worth a release tag, IMO 97f42037659eb3bd96eab8e653b5ed558426497c (#14) was bug fixes, patch release if at all 9498f0d4d1fffd0ff046dea366fc54ac6715240c (#15) was a bug fix, patch release if at all 2673c49640999b3f72f87a361c8c51b9bd31321d (#16) was the auto re-alias after uninstall feature; probably worth a minor version bump. No BC breaks.

That's pretty much all the work that I wanted to submit, so there shouldn't be another deluge of commits from me.

Last question, do you care about a travis-ci badge on the readme? I didn't see any of your other repos with travis badges, but then again, none of them had a .travis.yml. I'll add it if you don't mind, but wanted to check. People have feelings about those readme badges.

tpope commented 8 years ago

Alright let's give it a week or so of bake time to spare me the trouble of a followup point release.

I have never understood the point of the travis-ci badge. It should always been green, and, if not, what good does it do to alert random passersby to that fact?

jasonkarns commented 8 years ago

I have never understood the point of the travis-ci badge.

Mostly agree. However, I've found that my repos without the badges stay red longer than those with the badges. Mostly because I keep seeing the red badge when I'm interacting via github.

Case in point, had there been a badge on this repo, I doubt the tests would have remained red for the past year. Though that's probably more to do with the travis build not actually being enabled than lacking the badge. But I know that I personally don't regularly visit travis' dashboard except by clicking through red badges or red PR builds.

Again, no strong feeling either way. Your preference

jasonkarns commented 8 years ago

Just merged #19 which has 3 bug fixes related to semver versions

tpope commented 8 years ago

Yeah I saw, I'm resetting the bake timer :)

tpope commented 8 years ago

Can you give me a few bullets summing up your user facing changes for the release notes? I started to put some together and I realized I am not sure which bug fixes are to new features (and thus shouldn't be included) and which are to existing features in 1.0.1 (and thus should be). My general technique is git log --reverse --pretty=format:%s v1.0.1.. and then filter out the crap.

jasonkarns commented 8 years ago

11 (155dc4404a2eac0a134d6357ad2d0b7ea302e302)

Invalid usage now prints just --usage output, not full help output.
Invalid usage now exits as an error
Invalid unalias usage now prints help for unalias, not alias
Now accepts --help flag (same as rbenv help alias)

14 (97f42037659eb3bd96eab8e653b5ed558426497c)

rbenv alias <version> --auto now accepts semver style and engine-version style (jruby-1.7.8) versions in addition to the previously supported patch style (1.9.2-p290) versions
rbenv alias <version> --auto now sorts numerically instead of lexically
rbenv alias --auto now works for semver and engine-version style versions in addition to the previously supported patch style versions

16 (2673c49640999b3f72f87a361c8c51b9bd31321d)

rbenv alias <version> --auto now removes orphaned/invalid aliases
Now automatically runs auto-aliasing via uninstall hook

19 (e55df2bb31957ad62ff6b2116f16eef6b76fe51c)

Support semver versions with segments of 2 digits or more (e.g. 2.2.11)