Release(s)

[jasonkarns]

@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:

155dc44 (#11) was trivial feature, not worth a release tag, IMO
97f4203 (#14) was bug fixes, patch release if at all
9498f0d (#15) was a bug fix, patch release if at all
2673c49 (#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]

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]

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]

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

[tpope]

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

[tpope]

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]

#11 (155dc44)

• 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 (97f4203)

• 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 (2673c49)

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

#19 (e55df2b)

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

[blackjid]

please release this!

[blackjid]

any news on this?? @tpope
thanks

[blackjid]

pretty please!!

[tpope]

Remind me what the rush is?

On Thu, Jan 28, 2016 at 12:38 PM Juan Ignacio Donoso <
[email protected]> wrote:

pretty please!!

—
Reply to this email directly or view it on GitHub
#18 (comment).

[blackjid]

sorry... I really want to use this from the official release for my team.. and not from the branch...

[jasonkarns]

@blackjid everything is in master, so if rbenv-aliases is installed via git, all the features listed above are already present. A release will only bump the version and add a git tag, which is necessary for an update in homebrew.

[blackjid]

yes, yo are right... and that's really the reason... because I'm using homebrew to deploy this plugin...

[tpope]

Pushed.

[blackjid]

thanks!