Rack::File -> Rack::Files

[postmodern]

Renamed Rack::File to Rack::Files, since it can serve arbitrary files from a root directory. Once we can remove Rack::File, we can no longer worry about name conflicts between ::File and Rack::File.

[postmodern]

To be clear, I left a lib/rack/file.rb file and Rack::File constant, which can be removed on a major version bump. Although, I'm unsure if or when a deprecation warning message should be added to the lib/rack/file.rb file, or if a deprecation notice in the ChangeLog would suffice?

[krainboltgreene]

This is an intelligent change, and makes literary and context sense.

[josevalim]

Backwards incompatible. IIRC Rails relies on Rack::File (and potentially others tools besides Rails).

[krainboltgreene]

So mark it for a point release.

On Jan 12, 2012, at 1:34 PM, José Valimreply@reply.github.com wrote:

Backwards incompatible. IIRC Rails relies on Rack::File (and potentially others tools besides Rails).

---

Reply to this email directly or view it on GitHub:
#305 (comment)

[josevalim]

It needs to be deprecated first.

[postmodern]

@josevalim Like I said before, I left a Rack::File and rack/file.rb behind specifically for backwards compatibility. I'm leaving it up to the Rack team how they wish to deprecate the constant (I didn't get a clear answer as to how they normally handle deprecations).

[raggi]

Needs rebasing now. I'm not ignoring this, I'm just trying to decide when I want to pull the trigger. I think my answer is "for rails 4". The main point being, I don't really want to maintain too much heavy deviance and do continual cross-patching. I'll keep you posted ofc.

[postmodern]

Rebased! Tests pass.

Should we bring @rkh into this discussion, as changes to Rack can also impact Sinatra? Also, until Rack::File is completely removed, all Rack code will have to continue using the awkward ::File style. There should be a grace period where Rack::File and Rack::Files co-exist.

[raggi]

The issues will be broad I believe. I'd expect this will also hit ramaze and maybe padrino separately.

Happy to add a deprecation notice in the next 1.4.x release. I'm not sure how long to give it, but I'd like to give it a while to avoid lots of merge issues. On that note, to reduce merge conflicts, I'd prefer to alias to Files first, and move it over when the deprecation is executed. This will save on maintenance time. (see multipart back ports :'( )

[raggi]

Thanks for rebasing!!!

[raggi]

Due to signature changes that have already occurred, I'm leaving this until 1.6 at the earliest.

[tenderlove]

This seems fine to me. AFAIK, master is 1.6. Should we merge this? < @raggi

[ioquatix]

@tenderlove I can rebase and merge this. I can add a deprecation notice and aim for removing in 3.0?

[tenderlove]

@ioquatix sounds great! Go for it

[ioquatix]

Okay rebasing today.

[ioquatix]

Merged.