New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for github releases #350

Closed
hadley opened this Issue Sep 26, 2013 · 10 comments

Comments

Projects
None yet
3 participants
@hadley
Member

hadley commented Sep 26, 2013

@randy3k

This comment has been minimized.

Contributor

randy3k commented Mar 29, 2014

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

@krlmlr krlmlr referenced this issue Apr 14, 2014

Closed

update_github() #457

@krlmlr

This comment has been minimized.

Member

krlmlr commented Apr 14, 2014

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

This comment has been minimized.

Contributor

randy3k commented Apr 14, 2014

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

This comment has been minimized.

Member

hadley commented Apr 14, 2014

@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

This comment has been minimized.

Contributor

randy3k commented Apr 14, 2014

@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

This comment has been minimized.

Member

krlmlr commented Apr 14, 2014

@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

This comment has been minimized.

Member

hadley commented Apr 14, 2014

@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

This comment has been minimized.

Member

hadley commented Apr 14, 2014

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

@krlmlr

This comment has been minimized.

Member

krlmlr commented Apr 14, 2014

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

This comment has been minimized.

Contributor

randy3k commented Apr 14, 2014

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@*.

@hadley hadley closed this in #475 Aug 22, 2014

hadley added a commit that referenced this issue Aug 22, 2014

Merge pull request #475 from krlmlr/350-github-releases
Allow installing the latest GitHub release. Closes #350.

@lock lock bot locked and limited conversation to collaborators Sep 18, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.