Add support for github releases

[hadley]

http://developer.github.com/v3/repos/releases/

[randy3k]

any way to install the latest release via install_github?
now, it is only possible to install a particular tag/commit

[krlmlr]

This would be a great feature. How about the following syntax:

install_github("user/repo[/subdir]*")

? (Of course, in addition to a new parameter to install_github.)

[randy3k]

I think a better way may be install_github("user/repo") will install the latest release by default, if there are no releases, then use the latest commit.

Because releases are supposed to be installable but the latest commit does not.

[hadley]

@randy3k except that many packages don't use releases, and the goal of install_github() is to get you the latest dev version, not the latest released version (which you'd normally get from CRAN)

@krlmlr how about something like install_github("user/repo@_latest"), install_github("user/repo@_released")?

[randy3k]

@hadley , the reason I brought up this is to avoid dependence on CRAN. I feel like some developers are not pushing their releases to CRAN due to its strict R CMD check.

In this way, developers will get back the controls. It may be even more useful to allow binary releases for different platforms (ignore possible security considerations).

[krlmlr]

@hadley: A single-character flag such as the asterisk is much shorter, and easier to type. Hash and @ are taken, they also mean something in Git/GitHub. I'm not sure there's a special character connected with releases, except that they are a kind of a tag. So, the @ would be appropriate -- how about a combination of @ with another special character, like @* for "latest" (intuition: any robust ref) and @! for "released"?

@randy3k: CRAN discourages too frequent releases, they suggest

once every 1-2 months seems appropriate.

[hadley]

@randy3k replacing CRAN is outside the scope of devtools.

@krlmlr I don't think we need both latest and released. Maybe we should pick a name that otherwise can't be used as a tag - e.g. "They cannot have ASCII control characters (i.e. bytes whose values are lower than \040, or \177 DEL), space, tilde ~, caret ^, or colon : anywhere.".

[hadley]

@krlmlr Or we could go crazy and do user/repo@• or similar ;)

[krlmlr]

From man git-check-ref-format:

Git imposes the following rules on how references are named:

1. ...
2. ...
3. ...
4. They cannot have ASCII control characters (i.e. bytes whose values are lower than \040, or \177 DEL), space, tilde ~, caret ^, or colon : anywhere.
5. They cannot have question-mark ?, asterisk *, or open bracket [ anywhere. See the --refspec-pattern option below for an exception to this rule.
6. ...
7. They cannot end with a dot ..
8. ...
9. They cannot be the single character @.

And below:

--refspec-pattern
Interpret as a reference name pattern for a refspec (as used with remote repositories). If this option is enabled, is allowed to contain a single * in place of a one full pathname component (e.g., foo/*/bar but not foo/bar*).

To me, this means we can use at least @ + any of ~^:?*.@ without having to fear conflicts. I still prefer @*.

[randy3k]

how about user/repo@* for latest release and user/repo^ for development (^ means HEAD) and mapping user/repo to user/repo^ with an option to user/repo@*.