11 ms·
Exactly! We've been doing the same thing – releasing only to GitHub because it's so easy and fun (and easier now that they e-mail you when the gem fails to buil
by djanowski 17y ago
Exactly! We've been doing the same thing – releasing only to GitHub because it's so easy and fun (and easier now that they e-mail you when the gem fails to build...)
The idea behind Joe is that if you're already releasing to GitHub, it's really easy to release to RubyForge as well with a single command. No need to wrap your whole project inside something like Hoe. You're already generating a gemspec for GitHub, why not using it for RubyForge?
Plus there's the addition of the ERb template to produce the gemspec (which is completely optional), but that's the best way I've found to maintain my gem specification, especially the files I want to ship.
- jamesbritt 17y ago" You're already generating a gemspec for GitHub, why not using it for RubyForge?" Because then I first have to ask Tom to create new project for me. :) That's not a tremendous barrier, but with GitHub, whenever I get some code that looks like something I can spin off as a gem, it's almost frictionless to do it GitHub style. That said, I have to give Joe a spin and see how it stacks up against Mr. Bones, which is what I've been using.
- djanowski 17y ago:-) Fortunately they changed their minds and gems are auto-approved now, so the barrier is still there, just a little bit easier to lift ;-) Again, GitHub rocks. We tried to create a simple script to make it easier for us to also deploy to RubyForge (mainly because of the username prepending and the --source). We'll be looking forward to your feedback, James!