README: reference yahns
Because nobody has time to read about all the options Rainbows!
provides. yahns is basically XEpollThreadPool, with minor
improvements which weren't easily supportable with other
concurrency options.

switch docs + website to olddoc
wrongdoc was difficult to maintain because of the tidy-ffi
dependency and the HTML5 changes in Darkfish could not be
handled well by Tidy.
olddoc is superior as it generates leaner HTML which loads faster,
requires less scrolling and less processing power to render.
Aesthetic comparisons are subjective of course but completely
unimportant compared to speed and accessibility.
The presence of images and CSS on the old (Darkfish-based) site
probably set unreasonable expectations as to my ability and
willingness to view such things. No more, the new website is
entirely simple HTML which renders well with even the wimpiest
browser (hell, olddoc even tries to generate readable raw HTML).

update dependencies for Ruby 2.2.0dev
This will allow me to test for unintentional breakage in 2.2.0.
Part of the reason for putting this project on maintenance mode
is because many of the libraries we depend on have not kept up
with the latest changes to Ruby. So we will disable many tests
for 2.2+ to ensure the core parts remain working.

Rainbows! 4.6.2 - see you on the other side2014-05-12T07:01:27ZEric Wongnormalperson@yhbt.netEric Wongnormalperson@yhbt.net2014-05-12T07:01:27Zhttp://repo.or.cz/w/rainbows.git/commitdiff/64a68a2a457d5f57969261689c13d633f6721ed3

Rainbows! 4.6.2 - see you on the other side
This release updates documentation to reflect the migration of the
mailing list to a new public-inbox[1] instance. This is necessary
due to the impending RubyForge shutdown on May 15, 2014.
The public-inbox address is: rainbows-public@bogomips.org
(no subscription required, plain text only)
ssoma[2] git archives: git://bogomips.org/rainbows-public
browser-friendly archives: http://bogomips.org/rainbows-public/
As evidenced by our git history, Rainbows! development has stagnated
over the years. Rainbows! was designed to be an unopinionated
exploration into various concurrency options offered in the Ruby
ecosystem.
In recent years, I have come to favor the one-shot-based,
worst-of-all-worlds design of yahns: http://yahns.yhbt.net/README
Without the exploration from Rainbows!, yahns may not exist today.
Disclaimer: Rainbows! has always been intolerant of buggy/broken code in
libraries and apps. yahns is even less tolerant of buggy/broken code,
as the SIGKILL-based timeout mechanism inherited unicorn is completely
gone. On the other hand, yahns has reasonable defaults so you do not
have to read documentation to configure it.
[1] policy: http://public-inbox.org/ - git://80x24.org/public-inbox
an "archives first" approach to mailing lists
[2] mechanism: http://ssoma.public-inbox.org/ - git://80x24.org/ssoma
some sort of mail archiver (using git)

add script for redirecting to new site2014-05-06T21:12:56ZEric Wonge@80x24.orgEric Wonge@80x24.org2014-05-06T21:12:56Zhttp://repo.or.cz/w/rainbows.git/commitdiff/d4ba676aab09d3d4c51146661dcea11e5aa99f0c

event_machine: update for unicorn 4.8.x
unicorn 4.8.x shutdown handling is different and no longer removes
items from the event loop. So we must do that ourselves to enable
graceful shutdown. Otherwise, we'll time out on shutdowns and
the master will forcibly kill us.

Rainbows! 4.6.0 - fix unicorn 4.8.0 compatibility
The unicorn 4.8.0 internal changes unfortunately broke some
unoffically supported behavior we depended on. This release fixes
that, but as a result, we lose compatibility of older unicorn
versions. (Oops!, oh well... :x)
There's also minor bugfixes and documentation updates.
In order to ease transitions to future versions of the GPL, we are
now "GPLv2 or later" instead of explicitly GPLv2 + GPLv3(-only).
The old Ruby 1.8 license remains an option. If the FSF turns out
a horrible GPLv4, users are free to continue using GPLv2 or GPLv3.

license: allow all future versions of the GNU GPL
There is currently no GPLv4, so this change has no effect at the
moment.
In case the GPLv4 arrives and I am not alive to approve/review it,
the lesser of evils is have give blanket approval of all future GPL
versions (as published by the FSF). The worse evil is to be stuck
with a license which cannot guarantee the Free-ness of this project
in the future.
This unfortunately means the FSF can theoretically come out with
license terms I do not agree with, but the GPLv2 and GPLv3 will
always be an option to all users.