From: Tom Copeland on 18 Jun 2010 19:04
On Jun 18, 2010, at 12:10 PM, Caleb Clausen wrote:
> On 6/16/10, Tom Copeland <tom(a)infoether.com> wrote:
>> True, yup, Redmine has a files tab but I think it's pretty much a linear
>> How much of the RubyForge Package/Release/File structure do you think we
> Personally, I don't see much point to having rubyforge model releases.
> A separate directory for each package is clearly needed, but I just
> want a place to dump my tarballs. Having to 'create a release' each
> time I do that is (a little bit of) extra work. The 'release' of a
> file is implicitly stored in the file's name anyway.
Hm, interesting, yeah, seems like the date and filename (foobar-1.2.3.tar.gz) gets you most of the way there.
> While we're on the subject, it would be extremely nice if the urls to
> files were friendlier. Something like
> http://rubyforge.org/<packagename>/<filename> is what I would like to
> see, rather than the current scheme which involves numbers in the url
> as I recall. (OTOH, files currently on rubyforge might need to keep
> their current urls as well, otherwise you risk breaking external
Cool, yup, I think Redmine generates reasonable URLs for files.
For external links, maybe we can generate a huge rewritemap... hm, or have a custom route that looks things up by "old_frs_file_id"... well, lots of possibilties, but yup, it would be good to keep those external links working.
From: Tom Copeland on 18 Jun 2010 19:05
On Jun 18, 2010, at 1:20 PM, Luis Lavena wrote:
> Linear works for me. I'm worried that file releases for RubyInstaller,
> tar files for projects like SQLite3-Ruby and others are lost.
> Just that.
Cool. No worries, yup, we'll keep all that data (and the files) in some form.
> RubyForge release cycle is overkill, that one of the reasons I think
> gemcutter make gem releases blossom, it lowered the release barrier.
Excellent, so sounds like a lighter release mechanism is a good thing... glad to hear it....