Or maybe integrate GH with http://gemcutter.org/ which I only became aware of about five minutes after I wrote that post. ;-)
Maybe a post commit hook to gemcutter to pull the latest GH gem release to gemcutter as the latest canonical release (minus the github username prefix). Glenn On Aug 13, 9:48 am, Glenn Rempe <[email protected]> wrote: > Chris, > > Wouldn't it be nice if this new functionality allowed us to build & > host the canonical version of a gem (e.g. if I manage the grempe- > amazon-ec2 gem which gets auto-built, it would be nice if I could > specify that mine is the 'master' repo for this project and have it > build and host 'amazon-ec2' as well for 'official' releases. It would > be optimal if this were automated, but manual upload would work in a > pinch (or via a rake task). The goal here is to replace and eliminate > the use of RubyForge. Personally I have no other reason to use > rubyforge other than this use-case. > > If you allow manual uploads, how would you plan to handle naming > conflicts? Would all uploads have to be namespaced under my GH user > name? > > Thx > > On Aug 12, 10:08 am, Chris Wanstrath <[email protected]> wrote: > > > > > On Wed, Aug 12, 2009 at 8:33 AM, trans<[email protected]> wrote: > > > So I gave it some thought and I think a potential solution for > > > improvement in the future is to allow the developer to designate a > > > "distribution folder" in their repository in which the packages can be > > > stored. GitHub can still automatically generate the .gem if the > > > developer wants. Or, they can just build their own gem(s) and use git > > > to push it to the repo. Since git is so efficient and the .gem has to > > > be stored somewhere anyway, it's really not a big deal to have it in > > > the repo. This way the developer can remove gems he/she no longer > > > wants to support at his/her discretion, as well as add platform gems > > > if need be. It also opens GitHub up for supporting other distributed > > > packages systems in the future, such as Debians' apt-get. > > > That's not a bad idea. In-house we've been talking about using > > GitHub's "Downloads" functionality - we'll serve any .gem you upload. > > > To streamline the process, we're talking about adding "upload" > > capabilities to the GitHub gem. So upload a new gem might be as easy > > as `gh upload blah.gem`. > > > -- > > Chris Wanstrathhttp://github.com/defunkt --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "GitHub" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/github?hl=en -~----------~----~----~----~------~----~------~--~---
