Call for 1.1.0 release

5 views
Skip to first unread message

Joshua Peek

unread,
Dec 21, 2009, 10:11:49 PM12/21/09
to Rack Development
I'd to cut a 1.1 release before the new year. I'm going to put in the
work for the release notes and actual gem push. Now that we are on
Gemcutter, the entire rack core team has push access.

Heres an overview of the major changes:

* Relaxes SPEC to allow subclasses.
- This is the major change I want to get out there. Right now Rails
2.x needs to monkey patch Lint to work around this.
* Refactored rackup into Rack::Server
* Removed Auth::OpenID
* Nested parameter and multipart generation improvements to Mock
* Pull in some useful contrib middleware: Config, ETag, Runtime,
Sendfile
* rack.logger extension specification
* Various bug fixes and optimizations

Please test rack/master and make sure your libraries are ready.

I'd like to get a +1 from all the rack core members before anything is
released.

Christian Neukirchen

unread,
Dec 22, 2009, 8:02:29 AM12/22/09
to rack-...@googlegroups.com

+1, but please let me have a look over it before you release.
I can update the site and rubyforge then.

--
Christian Neukirchen <chneuk...@gmail.com> http://chneukirchen.org

Ryan Tomayko

unread,
Dec 22, 2009, 5:52:29 PM12/22/09
to rack-...@googlegroups.com

Tentative +1. I'm looking at a diff of 202afb4...master -- is that right?

Rack, Sinatra, and Rack::Cache test suites all pass under MRI
1.8.6/1.8.7 and REE 1.8.7. I can't get test-spec to run under 1.9 for
some reason so I haven't been able to test there.

Also, I have a few minor bugs I'd like to get in if possible. They
should be straightforward. I'll try to get patches to the list today.

Thanks,
Ryan
--
# tomayko.com/about

Eric Wong

unread,
Dec 24, 2009, 5:49:56 PM12/24/09
to rack-...@googlegroups.com
Joshua Peek <jo...@joshpeek.com> wrote:
> I'd to cut a 1.1 release before the new year. I'm going to put in the

Hi, I've started adding specs for (optional) "rack.io" and Mongrel
support as well. It's pretty lightweight in that it just requires
an IO.select-able IO object or StringIO (for testing)..

Perhaps it can go into 1.1 with some review/comments.

It's useful for at least two purposes.

* It can be used to implement Web Sockets or other alternative
sub-protocols with the HTTP connection.

* It can be used to detect client disconnects to avoid needlessly
performing expensive operations:

mid: <8b5b448c-d311-4472...@r5g2000prh.googlegroups.com>
http://groups.google.com/group/rack-devel/browse_thread/thread/5e5b52892f5e9353


I'm also thinking of a way to integrate it with EM-based servers like
Thin so it can be used with existing Thin deployments.


The code is in the "rack.io" branch of my git repo:
* git://git.bogomips.org/rack
* http://git.bogomips.org/cgit/rack.git/log/?h=rack.io

Shortlog:

Eric Wong (2):
Rack::Lint understands "rack.io" env
add "rack.io" to Mongrel request

--
Eric Wong

Joshua Peek

unread,
Dec 24, 2009, 6:40:58 PM12/24/09
to rack-...@googlegroups.com
Hey Eric,

Raw io access has been on my wish list for a while. I'm totally +1 but
do you think we can hold off? I'd like to put together the release
sometime next week before the new year.

Though there was a long year gap between 1.0 and 1.1, it doesn't mean
1.2 needs to be that far off. I'd like to speed up the release
schedule for these new ideas.

--
Joshua Peek

Scytrin dai Kinthra

unread,
Dec 24, 2009, 6:57:07 PM12/24/09
to rack-...@googlegroups.com
+1 for a New Years release.

--
stadik.net

Eric Wong

unread,
Dec 24, 2009, 7:24:51 PM12/24/09
to rack-...@googlegroups.com
Joshua Peek <jo...@joshpeek.com> wrote:
> Hey Eric,
>
> Raw io access has been on my wish list for a while. I'm totally +1 but
> do you think we can hold off? I'd like to put together the release
> sometime next week before the new year.

Sure thing on holding off.

I'm very glad to know there's interest for this idea. I'll try
to cook up some examples of ways to use it with async servers, too...

> Though there was a long year gap between 1.0 and 1.1, it doesn't mean
> 1.2 needs to be that far off. I'd like to speed up the release
> schedule for these new ideas.

Yeah, the gap between releases got me a bit worried.

--
Eric Wong

James Tucker

unread,
Dec 26, 2009, 9:38:38 AM12/26/09
to rack-...@googlegroups.com

On 24 Dec 2009, at 23:40, Joshua Peek wrote:

> Hey Eric,
>
> Raw io access has been on my wish list for a while. I'm totally +1 but
> do you think we can hold off? I'd like to put together the release
> sometime next week before the new year.
>
> Though there was a long year gap between 1.0 and 1.1, it doesn't mean
> 1.2 needs to be that far off. I'd like to speed up the release
> schedule for these new ideas.

+1 we need to hold off, there's more to discuss in this area.

James Tucker

unread,
Dec 26, 2009, 9:41:23 AM12/26/09
to rack-...@googlegroups.com

On 25 Dec 2009, at 00:24, Eric Wong wrote:

> Joshua Peek <jo...@joshpeek.com> wrote:
>> Hey Eric,
>>
>> Raw io access has been on my wish list for a while. I'm totally +1 but
>> do you think we can hold off? I'd like to put together the release
>> sometime next week before the new year.
>
> Sure thing on holding off.
>
> I'm very glad to know there's interest for this idea. I'll try
> to cook up some examples of ways to use it with async servers, too...

Eric - I had a report from one of the async_sinatra users who tried out rainbows with EM, and found that the API didn't actually line up with what Thin was doing. I really want to devote some more time with this but I've been very busy. Sadly due to this I don't want to say stop, but, well, I want to say please check existing apps against it. I guess could you check async_*.ru from github.com/macournoyer/thin/master/tree/examples/async_*.ru, as from what was reported, they're not working with the rainbows implementation of the deferrablebody hacks.

Eric Wong

unread,
Dec 26, 2009, 6:27:32 PM12/26/09
to rainbo...@rubyforge.org, rack-...@googlegroups.com
Moving to rainbows list

James Tucker <jftu...@gmail.com> wrote:
> Eric - I had a report from one of the async_sinatra users who tried
> out rainbows with EM, and found that the API didn't actually line up
> with what Thin was doing. I really want to devote some more time with
> this but I've been very busy. Sadly due to this I don't want to say
> stop, but, well, I want to say please check existing apps against it.
> I guess could you check async_*.ru from
> github.com/macournoyer/thin/master/tree/examples/async_*.ru, as from
> what was reported, they're not working with the rainbows
> implementation of the deferrablebody hacks.

Hi James, thhanks for the heads up.

Rainbows! doesn't handle deferrable bodies yet (I didn't look closely enough
the first time around), so it can't do everything Thin does with EM, yet.
It's already in the TODO, I'll make a mental note to work on it sooner.

--
Eric Wong

Eric Wong

unread,
Dec 30, 2009, 5:47:29 AM12/30/09
to rainbo...@rubyforge.org, rack-...@googlegroups.com

Rainbows! 0.90.1 should support deferrable bodies needed for async apps
on EM.

I stole the async_app.ru and async_tailer.ru examples from Thin and made
them a part of the integration tests (in t/t04??-*.sh).


The app.deferred?(env) isn't supported, yet. It's in the TODO and I
don't think many people use it... (correct me if I'm wrong).

--
Eric Wong

Eric Wong

unread,
Dec 30, 2009, 8:22:52 PM12/30/09
to rack-...@googlegroups.com
Ryan Tomayko <r...@tomayko.com> wrote:
> Rack, Sinatra, and Rack::Cache test suites all pass under MRI
> 1.8.6/1.8.7 and REE 1.8.7. I can't get test-spec to run under 1.9 for
> some reason so I haven't been able to test there.

I sent the patches ad the end of this message to Christian which should
get test-spec mostly working under 1.9 (though I can't get test-spec to
pass its own tests).

Under all versions of Ruby I tested, the basic test suite fails
spec_rack_logger.rb:

<"Program started\nNothing to do!\n"> expected to be =~
</INFO\ \-\-\ :\ Program\ started/>.

It looks like the Logger formatter gets clobbered somewhere,
running that test standalone seems to work fine, though.

Running Ruby 1.9.2dev trunk r26127, everything else passes except the
following because of a Marshal format change:

test_spec {Rack::Session::Cookie} 005 [creates a new cookie with integrity hash](Rack::Session::Cookie) [/home/ew/rack/test/spec_rack_session_cookie.rb:55]:
<"rack.session=BAh7BkkiDGNvdW50ZXIGOgZFRmkG%0A--2548b2a97e67656c3457b9a5cb43b65a83715cbc; path=/"> expected to be =~
</rack\.session=BAh7BkkiDGNvdW50ZXIGOg1lbmNvZGluZyINVVMtQVNDSUlpBg%3D%3D%0A\-\-d7a6637b94d2728194a96c18484e1f7ed9074a83/>.


test-spec patches below:
--------------------------------- 8< ---------------------------------

Wed Dec 30 23:22:17 UTC 2009 normal...@yhbt.net
* add "spec" pattern for automatic tests

test-unit 2.0.5 (required for Ruby 1.9) doesn't automatically
glob patterns beginning with "spec".
Wed Dec 30 22:24:51 UTC 2009 normal...@yhbt.net
* Rakefile: String#each -> String#each_line for 1.9

String#each no longer exists in Ruby 1.9
diff -rN -u old-testspec/bin/specrb new-testspec/bin/specrb
--- old-testspec/bin/specrb 2009-12-31 01:00:08.000000000 +0000
+++ new-testspec/bin/specrb 2009-12-31 01:00:08.000000000 +0000
@@ -104,4 +104,10 @@
runner = Test::Unit::AutoRunner.new true
runner.process_args(argv) ||
abort("internal error calling Test::Unit, please report a bug")
+
+# needed for test-unit 2.0.5 under Ruby 1.9
+if automatic && RUBY_VERSION.to_f >= 1.9
+ runner.pattern << %r{\Aspec[_\-].+\.rb\z}m
+end
+
exit runner.run
diff -rN -u old-testspec/Rakefile new-testspec/Rakefile
--- old-testspec/Rakefile 2009-12-31 01:00:08.000000000 +0000
+++ new-testspec/Rakefile 2009-12-31 01:00:08.000000000 +0000
@@ -27,7 +27,7 @@
count = 0
tag = "0.0"

- changes.each("\n\n") { |change|
+ changes.each_line("\n\n") { |change|
head, title, desc = change.split("\n", 3)

if title =~ /^ \*/

--
Eric Wong

Reply all
Reply to author
Forward
0 new messages