Date | Commit message (Collapse) |
|
It does not look like we'll be compatible with Ruby 3.0 with
the plan for immutable string literals.
However, keep in mind 3.0 is still many years away and
decisions can change, so it would be premature to stop
assuming frozen string literals this year.
ref: https://bugs.ruby-lang.org/issues/11473
|
|
rdoc_options is no longer necesary with olddoc as olddoc can
infer document titles and only generates cgit-compatible URLs
to source code.
|
|
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.
|
|
Both sites are gone.
|
|
test-unit 3 and minitest 5 will have equal support status as a
bundled gems when Ruby 2.2.0 is released in December 2014. These
bundled gems will appear in the user-oriented tarball installations,
but do not get installed by "make install" when installing Ruby
from SVN or git.
test-unit appears to be actively maintained and good at keeping
backwards compatibility even on a major version change, so this
means no code changes on our end. I am not convinced switching to
minitest is worth the effort.
Cc: Ken Dreyer <ktdreyer@ktdreyer.com>
|
|
It seems unnecessary with current versions of RubyGems
supporting development dependencies.
|
|
Update the old mailing list info with our new public-inbox info.
The old mongrel.rubyforge.org links have been dead for years,
oh well. There's only a few days left of RubyForge left...
|
|
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.
|
|
This enables compatibility with metadata scanners such as
LicenseFinder[1].
The previously commented-out accessor was commented out
in September 2009 when ancient RubyGems were more prevalent.
By now (December 2012), those ancient versions of RubyGems
are unlikely to be around.
[1] https://github.com/pivotal/LicenseFinder
[ew: rewritten commit message]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
|
|
We should always be testing with the newest available versions
to watch for incompatibilities, even if we don't /require/ the
latest ones to run.
|
|
Hopefully it points people towards the mailing list
|
|
Oops, I suck at Ruby :x
|
|
This means we no longer waste an extra file descriptor per
worker process in the master. Now there's no need to set a
higher file descriptor limit for systems running >= 1024
workers.
|
|
kgio 2.4.1 portability should be better than 2.3, so
less user confusion and push them towards 2.4
|
|
It's required for RubyGems 1.8.x
|
|
People reinstalling would've pulled it in anyways, but
2.3.2 is the latest and has no known issues.
|
|
|
|
This is needed for IPv6 support, and 2.2.0 is nicer
all around for Rainbows! users. Updates wrongdoc
while we're at it, too.
|
|
Certain applications that already serve hundreds/thousands of requests a
second should experience performance improvements due to
Time.now.httpdate usage being removed and reimplemented in C.
There are also minor internal changes and cleanups for Rainbows!
|
|
Oops
|
|
The kgio 2.x series will maintain API compatibility
until 3.x, so it's safe to use any 2.x release.
|
|
wrongdoc factors out a bunch of common code from this
project into its own and removes JavaScript from RDoc
to boot.
|
|
The Kgio 2.x API is less brain-damaged than the 1.3.x series
was, and should solve API-compatibility problems with
dalli 0.11.1.
|
|
-N and -a switches no longer exist in rdoc 2.5
|
|
No reason to not use the latest and greatest!
|
|
kgio 1.3.1 fixes some cases for zero-length reads.
|
|
There was a backwards-incompatible API change,
but that didn't even affect us.
|
|
kgio 1.2.1 works around a bug for some *BSDs, some of which are
popular platforms for developers.
|
|
We use the latest and greatest whenever possible.
|
|
This provides the kgio_read! method which is like readpartial,
only significantly cheaper when a client disconnects on us.
|
|
This should hopefully make the non-blocking accept()
situation more tolerable under Ruby 1.9.2.
|
|
|
|
... And make the gemspec do minor un-RDoc-ing
|
|
|
|
So says the project website and documentation
|
|
|
|
In short: upgrade to Rails 2.3.4 (or later)
ref: http://mid.gmane.org/20091014221552.GA30624@dcvr.yhbt.net
Note: the workaround described in the article above only made
the issue more subtle and we didn't notice them immediately.
|
|
While Unicorn is one of very many Unix-only, pre-forking, shared
socket servers in existence, and Unicorn is _definitely_ not the
only server that only works *well* with fast clients, either.
But as far as we know, Unicorn is the first (and so far only)
server that emphasizes only working well with fast clients.
|
|
We hope to never require copyright assignment here...
|
|
It may have caused confusion that the licenses we're under
were incompatible with older Rubygems which is not the case.
|
|
This allows `gem check -t unicorn` to work. The rest of
the tests run with GNU make but I don't have the patience
to get them working with pure-Ruby since I can't stand
running those tests sequentially anyways.
|
|
Not sure if anybody runs tests with Rubygems directly
(instead of unpacking the source tree, but it's there)
|
|
"licenses=" is not in older Rubygems and some organizations
are still stuck on those...
|
|
|
|
* Manifest/CHANGELOG can be maintainance is painful.
I really hate having those in the source tree when
I have a version control system that already:
1) encourages me to make meaningful commits
2) is highly scriptable for generating manifests/changelogs
* hand-rolled gemspec allows more control for specifying
pre-release gem versions
* Less magic over what the `rubyforge` command does, being
able to spawn $VISUAL on changelogs/release notes and make
edits on them is nice.
Additionally I still strongly prefer GNU make over Rake for many
tasks since it offers better parallelization and some things are
easier *for me* in shell than Ruby.
|