Jeremy Evans

That's cool, no rush. Thanks for taking the time to look at this and respond. BTW, the way I found out about Tabula is that the auditors I work with...

Even if this can't be cleanly tested, it's clearly better to raise an exception instead of returning false. If you look at the README, it's clear that execute is never...

The other approach is removing in 4.0 instead of 3.1. I'm fine removing in 4.0 instead of 3.1 if that is was @rafaelfranca prefers. I'm not OK removing in 3.0...

> What about pushing deprecation notices into a final 2.x release? I'm strongly against introducing deprecation warnings in a tiny release. I'm fine with removal of deprecated features in either...

@ioquatix and I discussed this yesterday. I think we agreed to remove the code in 3.1, unless @tenderlove would prefer to keep support until 4.0. Rack doesn't advertise semantic versioning....

I'm against this and don't think the minor benefits are worth the backwards compatibility cost. Completely breaking backwards compatibility at this stage in rack's lifecycle makes is a very bad...

As I mentioned in https://github.com/rack/rack/issues/1878#issuecomment-1110034922, I'm against this proposal. Completely breaking backwards compatibility at this stage in rack's lifecycle makes is a very bad trade off, IMO. If given a...

@tenderlove I don't think it's a good idea to change the object passed to middleware/applications. Part of your comment makes this appear to be opt-in, which is not nearly as...

> > You would have to complicate all middleware that ship with rack to deal with both env hash and Rack::Request, and all external middleware and all applications would have...

If the issue is middleware that ship with Rack, as an alternative to this, I volunteer to modify all middleware that ship with rack to not rely on Rack::Request.