kotovalexarian-likes-github
/
sinatra
mirror of https://github.com/sinatra/sinatra
1
0
Fork 0
Code Releases Activity

Merge pull request #929 from burningTyger/master 

some updates to the German and English Readmes
This commit is contained in:
Katrina Owen 2014-09-13 18:02:11 -07:00
parent e9b31101e0 f3e381c6f2
commit e7f65ab3de
2 changed files with 221 additions and 89 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

158
README.de.md
View File

@ -1,7 +1,7 @@
# Sinatra
*Wichtig: Dieses Dokument ist eine Übersetzung aus dem Englischen und unter
Umständen nicht auf dem aktuellen Stand (aktuell Sinatra 1.4.2).*
Umständen nicht auf dem aktuellen Stand (aktuell Sinatra 1.4.5).*
Sinatra ist eine
[DSL](http://de.wikipedia.org/wiki/Domänenspezifische_Sprache), die das
@ -54,11 +54,13 @@ aufgerufen werden.
* [Markdown Templates](#markdown-templates)
* [Textile Templates](#textile-templates)
* [RDoc Templates](#rdoc-templates)
* [AsciiDoc Templates](#asciidoc-templates)
* [Radius Templates](#radius-templates)
* [Markaby Templates](#markaby-templates)
* [RABL Templates](#rabl-templates)
* [Slim Templates](#slim-templates)
* [Creole Templates](#creole-templates)
* [MediaWiki Templates](#mediawiki-templates)
* [CoffeeScript Templates](#coffeescript-templates)
* [Stylus Templates](#stylus-templates)
* [Yajl Templates](#yajl-templates)
@ -69,6 +71,7 @@ aufgerufen werden.
* [Benannte Templates](#benannte-templates)
* [Dateiendungen zuordnen](#dateiendungen-zuordnen)
* [Eine eigene Template-Engine hinzufügen](#eine-eigene-template-engine-hinzufgen)
* [Eigene Methoden zum Aufsuchen von Templates verwenden](#eigene-methoden-zum-aufsuchen-von-templates-verwenden)
* [Filter](#filter)
* [Helfer](#helfer)
* [Sessions verwenden](#sessions-verwenden)
@ -222,6 +225,17 @@ get '/posts.?:format?' do
end
```
Routen können auch den query-Parameter verwenden:
``` ruby
get '/posts' do
# matches "GET /posts?title=foo&author=bar"
title = params['title']
author = params['author']
# uses title and author variables; query is optional to the /posts route
end
```
Anmerkung: Solange man den sog. Path Traversal Attack-Schutz nicht deaktiviert
(siehe weiter unten), kann es sein, dass der Request-Pfad noch vor dem
Abgleich mit den Routen modifiziert wird.
@ -261,6 +275,7 @@ get '/', :provides => ['rss', 'atom', 'xml'] do
builder :feed
end
```
`provides` durchsucht den Accept-Header der Anfrage
Eigene Bedingungen können relativ einfach hinzugefügt werden:
@ -801,6 +816,27 @@ RDoc geschrieben werden. Es ist aber möglich, einen Renderer für die Templates
zu verwenden und einen anderen für das Layout, indem die
`:layout_engine`-Option verwendet wird.
#### AsciiDoc Templates
<table>
<tr>
<td>Abhängigkeit</td>
<td><a href="http://asciidoctor.org/" title="Asciidoctor">Asciidoctor</a></td>
</tr>
<tr>
<td>Dateierweiterungen</td>
<td><tt>.asciidoc</tt>, <tt>.adoc</tt> und <tt>.ad</tt></td>
</tr>
<tr>
<td>Beispiel</td>
<td><tt>asciidoc :README, :layout_engine => :erb</tt></td>
</tr>
</table>
Da man aus dem AsciiDoc-Template heraus keine Ruby-Methoden aufrufen kann
(ausgenommen `yield`), wird man üblicherweise locals verwenden wollen, mit
denen man Variablen weitergibt.
#### Radius Templates
<table>
@ -912,6 +948,44 @@ Creole geschrieben werden. Es ist aber möglich, einen Renderer für die Templat
zu verwenden und einen anderen für das Layout, indem die `:layout_engine`-Option
verwendet wird.
#### MediaWiki Templates
<table>
<tr>
<td>Abhängigkeit</td>
<td><a href="https://github.com/nricciar/wikicloth" title="WikiCloth">WikiCloth</a></td>
</tr>
<tr>
<td>Dateierweiterungen</td>
<td><tt>.mediawiki</tt> und <tt>.mw</tt></td>
</tr>
<tr>
<td>Beispiel</td>
<td><tt>mediawiki :wiki, :layout_engine => :erb</tt></td>
</tr>
</table>
Da man aus dem Mediawiki-Template heraus keine Ruby-Methoden aufrufen und auch
keine locals verwenden kann, wird man Mediawiki üblicherweise in Kombination mit
anderen Renderern verwenden wollen:
``` ruby
erb :overview, :locals => { :text => mediawiki(:introduction) }
```
Beachte: Man kann die `mediawiki`-Methode auch aus anderen Templates
heraus aufrufen:
``` ruby
%h1 Grüße von Haml!
%p= mediawiki(:greetings)
```
Da man Ruby nicht von MediaWiki heraus aufrufen kann, können auch Layouts nicht
in MediaWiki geschrieben werden. Es ist aber möglich, einen Renderer für die
Templates zu verwenden und einen anderen für das Layout, indem die
`:layout_engine`-Option verwendet wird.
#### CoffeeScript Templates
<table>
@ -1002,8 +1076,9 @@ json[:baz] = key
Die `:callback` und `:variable` Optionen können mit dem gerenderten Objekt
verwendet werden:
``` ruby
var resource = {"foo":"bar","baz":"qux"}; present(resource);
``` javascript
var resource = {"foo":"bar","baz":"qux"};
present(resource);
```
#### WLang Templates
@ -1023,9 +1098,9 @@ var resource = {"foo":"bar","baz":"qux"}; present(resource);
</tr>
</table>
Ruby-Methoden in wlang aufzurufen entspricht nicht den idiomatischen Vorgaben
von wlang, es bietet sich deshalb an, `:locals` zu verwenden. Layouts, die
wlang und `yield` verwenden, werden aber trotzdem unterstützt.
Ruby-Methoden in Wlang aufzurufen entspricht nicht den idiomatischen Vorgaben
von Wlang, es bietet sich deshalb an, `:locals` zu verwenden. Layouts, die
Wlang und `yield` verwenden, werden aber trotzdem unterstützt.
Rendert den eingebetteten Template-String.
@ -1177,6 +1252,23 @@ Dieser Code rendert `./views/application.mtt`. Siehe
[github.com/rtomayko/tilt](https://github.com/rtomayko/tilt), um mehr über
Tilt zu erfahren.
### Eigene Methoden zum Aufsuchen von Templates verwenden
Um einen eigenen Mechanismus zum Aufsuchen von Templates zu
implementieren, muss `#find_template` definiert werden:
``` ruby
configure do
set :views [ './views/a', './views/b' ]
end
def find_template(views, name, engine, &block)
Array(views).each do |v|
super(v, name, engine, &block)
end
end
```
## Filter
Before-Filter werden vor jedem Request in demselben Kontext, wie danach die
@ -1300,6 +1392,13 @@ Einstellungen ablegen.
set :sessions, :domain => 'foo.com'
```
Um eine Session mit anderen Apps und zwischen verschiedenen Subdomains
von foo.com zu teilen, wird ein *.* der Domain vorangestellt:
``` ruby
set :sessions, :domain => '.foo,com'
```
### Anhalten
Zum sofortigen Stoppen eines Request in einem Filter oder einer Route:
@ -1476,7 +1575,7 @@ get '/subscribe' do
"Angemeldet"
end
post '/message' do
post '/:message' do
connections.each do |out|
# Den Client über eine neue Nachricht in Kenntnis setzen
# notify client that a new message has arrived
@ -1711,7 +1810,8 @@ etag '', :new_resource => true, :kind => :weak
### Dateien versenden
Zum Versenden von Dateien kann die `send_file`-Helfer-Methode verwendet werden:
Um den Inhalt einer Datei als Response zurückzugeben, kann die
`send_file`-Helfer-Methode verwendet werden:
```ruby
get '/' do
@ -2125,6 +2225,9 @@ set :protection, :except => [:path_traversal, :session_hijacking]
<dd>Wird es auf <tt>true</tt> gesetzt, wird Thin aufgefordert
<tt>EventMachine.defer</tt> zur Verarbeitung des Requests einzusetzen.</dd>
<dt>traps</dt>
<dd>Einstellung, Sinatra System signalen umgehen soll.</dd>
<dt>views</dt>
<dd>Verzeichnis der Views. Leitet sich von der <tt>app_file</tt> Einstellung
ab, wenn nicht gesetzt.</dd>
@ -2172,8 +2275,15 @@ end
### Fehler
Der `error`-Handler wird immer ausgeführt, wenn eine Exception in einem
Routen-Block oder in einem Filter geworfen wurde. Die Exception kann über die
`sinatra.error`-Rack-Variable angesprochen werden:
Routen-Block oder in einem Filter geworfen wurde. In der
`development`-Umgebung wird es nur dann funktionieren, wenn die
`:show_exceptions`-Option auf `:after_handler` eingestellt wurde:
```ruby
set :show_exceptions, :after_handler
```
Die Exception kann über die `sinatra.error`-Rack-Variable angesprochen werden:
```ruby
error do
@ -2353,12 +2463,24 @@ Veränderungen zu `Sinatra::Base` konvertiert werden:
* Alle Routen, Error-Handler, Filter und Optionen der Applikation müssen in
einer Subklasse von `Sinatra::Base` definiert werden.
`Sinatra::Base` ist ein unbeschriebenes Blatt. Die meisten Optionen sind per
Standard deaktiviert. Das betrifft auch den eingebauten Server. Siehe
[Optionen und Konfiguration](http://sinatra.github.com/configuration.html) für
Details über mögliche Optionen.
Damit eine App sich ähnlich wie eine klassische App verhält, kann man
auch eine Subclass von `Sinatra::Application` erstellen:
``` ruby
require 'sinatra/base'
class MyApp < Sinatra::Application
get '/' do
'Hello world!'
end
end
```
### Modularer vs. klassischer Stil
Entgegen häufiger Meinungen gibt es nichts gegen den klassischen Stil
@ -2379,42 +2501,49 @@ werden:
<th>Szenario</th>
<th>Classic</th>
<th>Modular</th>
<th>Modular</th>
</tr>
<tr>
<td>app_file</td>
<td>Sinatra ladende Datei</td>
<td>Sinatra::Base subklassierende Datei</td>
<td>Sinatra::Application subklassierende Datei</td>
</tr>
<tr>
<td>run</td>
<td>$0 == app_file</td>
<td>false</td>
<td>false</td>
</tr>
<tr>
<td>logging</td>
<td>true</td>
<td>false</td>
<td>true</td>
</tr>
<tr>
<td>method_override</td>
<td>true</td>
<td>false</td>
<td>true</td>
</tr>
<tr>
<td>inline_templates</td>
<td>true</td>
<td>false</td>
<td>true</td>
</tr>
<tr>
<td>static</td>
<td>true</td>
<td>false</td>
<td>true</td>
</tr>
</table>
@ -2714,6 +2843,9 @@ auftreten.</dd>
Upgrade von einer früheren Version von Ruby zu Ruby 1.9.3 werden alle Sessions
ungültig. Ruby 1.9.3 wird bis Sinatra 2.0 unterstützt werden.</dd>
<dt>Ruby 2.x</dt>
<dd>2.x wird vollständig unterstützt.</dd>
<dt>Rubinius</dt>
<dd>Rubinius (Version >= 2.x) wird offiziell unterstützt. Es wird empfohlen, den
<a href="http://puma.io">Puma Server</a> zu installieren (<tt>gem install puma
@ -2738,8 +2870,8 @@ wir davon ausgehen, dass es nicht an Sinatra sondern an der jeweiligen
Implementierung liegt.
Im Rahmen unserer CI (Kontinuierlichen Integration) wird bereits ruby-head
(das kommende Ruby 2.1.0) mit eingebunden. Es kann davon ausgegangen
werden, dass Sinatra Ruby 2.1.0 vollständig unterstützen wird.
(zukünftige Versionen von MRI) mit eingebunden. Es kann davon ausgegangen
werden, dass Sinatra MRI auch weiterhin vollständig unterstützen wird.
Sinatra sollte auf jedem Betriebssystem laufen, dass einen funktionierenden
Ruby-Interpreter aufweist.

152
README.md
View File

@ -480,8 +480,9 @@ Available Options:
<dt>layout</dt>
<dd>
Whether to use a layout (<tt>true</tt> or <tt>false</tt>). If it's a Symbol, specifies
what template to use. Example: <tt>erb :index, :layout => !request.xhr?</tt>
Whether to use a layout (<tt>true</tt> or <tt>false</tt>). If it's a
Symbol, specifies what template to use. Example:
<tt>erb :index, :layout => !request.xhr?</tt>
</dd>
<dt>content_type</dt>
@ -821,8 +822,8 @@ template than for the layout by passing the `:layout_engine` option.
</tr>
</table>
Since you cannot call Ruby methods directly from an AsciiDoc template, you almost
always want to pass locals to it.
Since you cannot call Ruby methods directly from an AsciiDoc template, you
almost always want to pass locals to it.
#### Radius Templates
@ -949,8 +950,9 @@ template than for the layout by passing the `:layout_engine` option.
</tr>
</table>
It is not possible to call methods from MediaWiki markup, nor to pass locals to it.
You therefore will usually use it in combination with another rendering engine:
It is not possible to call methods from MediaWiki markup, nor to pass locals to
it. You therefore will usually use it in combination with another rendering
engine:
``` ruby
erb :overview, :locals => { :text => mediawiki(:introduction) }
@ -1086,8 +1088,8 @@ present(resource);
</tr>
</table>
Since calling ruby methods is not idiomatic in WLang, you almost always want to pass locals
to it. Layouts written in WLang and `yield` are supported, though.
Since calling ruby methods is not idiomatic in WLang, you almost always want to
pass locals to it. Layouts written in WLang and `yield` are supported, though.
### Accessing Variables in Templates
@ -1127,8 +1129,7 @@ end
This code is mostly equivalent to `erb :index, :layout => :post`.
Passing blocks to rendering methods is most useful for creating nested
layouts:
Passing blocks to rendering methods is most useful for creating nested layouts:
``` ruby
erb :main_layout, :layout => false do
@ -1147,8 +1148,7 @@ end
```
Currently, the following rendering methods accept a block: `erb`, `haml`,
`liquid`, `slim `, `wlang`.
Also the general `render` method accepts a block.
`liquid`, `slim `, `wlang`. Also the general `render` method accepts a block.
### Inline Templates
@ -1268,9 +1268,9 @@ get '/foo/*' do
end
```
After filters are evaluated after each request within the same
context as the routes will be and can also modify the request and response. Instance
variables set in before filters and routes are accessible by after filters:
After filters are evaluated after each request within the same context as the
routes will be and can also modify the request and response. Instance variables
set in before filters and routes are accessible by after filters:
``` ruby
after do
@ -1471,8 +1471,7 @@ end
```
Note that in the example above, you would ease testing and increase performance
by simply moving `"bar"` into a helper used by both `/foo`
and `/bar`.
by simply moving `"bar"` into a helper used by both `/foo` and `/bar`.
If you want the request to be sent to the same application instance rather than
a duplicate, use `call!` instead of `call`.
@ -1597,9 +1596,8 @@ This logger will automatically take your Rack handler's logging settings into
account. If logging is disabled, this method will return a dummy object, so
you do not have to worry about it in your routes and filters.
Note that logging is only enabled for `Sinatra::Application` by
default, so if you inherit from `Sinatra::Base`, you probably want to
enable it yourself:
Note that logging is only enabled for `Sinatra::Application` by default, so if
you inherit from `Sinatra::Base`, you probably want to enable it yourself:
``` ruby
class MyApp < Sinatra::Base
@ -1730,8 +1728,8 @@ end
```
To properly use caches, you should consider using `etag` or `last_modified`.
It is recommended to call those helpers *before* doing any heavy lifting, as they
will immediately flush a response if the client already has the current
It is recommended to call those helpers *before* doing any heavy lifting, as
they will immediately flush a response if the client already has the current
version in its cache:
``` ruby
@ -1793,7 +1791,8 @@ etag '', :new_resource => true, :kind => :weak
### Sending Files
To return the contents of a file as the response, you can use the `send_file` helper method:
To return the contents of a file as the response, you can use the `send_file`
helper method:
``` ruby
get '/' do
@ -1817,12 +1816,13 @@ The options are:
<dd>Value for Last-Modified header, defaults to the file's mtime.</dd>
<dt>type</dt>
<dd>Value for Content-Type header, guessed from the file extension if missing.</dd>
<dd>Value for Content-Type header, guessed from the file extension if
missing.</dd>
<dt>disposition</dt>
<dd>
Value for Content-Disposition header, possible values: <tt>nil</tt> (default),
<tt>:attachment</tt> and <tt>:inline</tt>
Value for Content-Disposition header, possible values: <tt>nil</tt>
(default), <tt>:attachment</tt> and <tt>:inline</tt>
</dd>
<dt>length</dt>
@ -1833,8 +1833,8 @@ The options are:
Status code to be sent. Useful when sending a static file as an error page.
If supported by the Rack handler, other means than streaming from the Ruby
process will be used. If you use this helper method, Sinatra will automatically
handle range requests.
process will be used. If you use this helper method, Sinatra will
automatically handle range requests.
</dd>
</dl>
@ -1876,8 +1876,7 @@ get '/foo' do
end
```
Some options, like `script_name` or `path_info`, can also be
written:
Some options, like `script_name` or `path_info`, can also be written:
``` ruby
before { request.path_info = "/" }
@ -1920,9 +1919,8 @@ end
### Dealing with Date and Time
Sinatra offers a `time_for` helper method that generates a Time object
from the given value. It is also able to convert `DateTime`, `Date` and
similar classes:
Sinatra offers a `time_for` helper method that generates a Time objectfrom the
given value. It is also able to convert `DateTime`, `Date` and similar classes:
``` ruby
get '/' do
@ -2116,7 +2114,9 @@ set :protection, :session => true
</dd>
<dt>bind</dt>
<dd>IP address to bind to (default: <tt>0.0.0.0</tt> <em>or</em> <tt>localhost</tt> if your `environment` is set to development.). Only used for built-in server.</dd>
<dd>IP address to bind to (default: <tt>0.0.0.0</tt> <em>or</em>
<tt>localhost</tt> if your `environment` is set to development). Only used
for built-in server.</dd>
<dt>default_encoding</dt>
<dd>Encoding to assume if unknown (defaults to <tt>"utf-8"</tt>).</dd>
@ -2126,8 +2126,8 @@ set :protection, :session => true
<dt>environment</dt>
<dd>
Current environment. Defaults to <tt>ENV['RACK_ENV']</tt>, or <tt>"development"</tt> if
not available.
Current environment. Defaults to <tt>ENV['RACK_ENV']</tt>, or
<tt>"development"</tt> if not available.
</dd>
<dt>logging</dt>
@ -2157,7 +2157,8 @@ set :protection, :session => true
</dd>
<dt>protection</dt>
<dd>Whether or not to enable web attack protections. See protection section above.</dd>
<dd>Whether or not to enable web attack protections. See protection section
above.</dd>
<dt>public_dir</dt>
<dd>Alias for <tt>public_folder</tt>. See below.</dd>
@ -2171,12 +2172,14 @@ set :protection, :session => true
<dt>reload_templates</dt>
<dd>
Whether or not to reload templates between requests. Enabled in development mode.
Whether or not to reload templates between requests. Enabled in development
mode.
</dd>
<dt>root</dt>
<dd>
Path to project root folder. Inferred from <tt>app_file</tt> setting if not set.
Path to project root folder. Inferred from <tt>app_file</tt> setting if not
set.
</dd>
<dt>raise_errors</dt>
@ -2208,14 +2211,13 @@ set :protection, :session => true
<dt>show_exceptions</dt>
<dd>
Show a stack trace in the browser when an exception
happens. Enabled by default when <tt>environment</tt>
is set to <tt>"development"</tt>, disabled otherwise.
Show a stack trace in the browser when an exception happens. Enabled by
default when <tt>environment</tt> is set to <tt>"development"</tt>,
disabled otherwise.
</dd>
<dd>
Can also be set to <tt>:after_handler</tt> to trigger
app-specified error handling before showing a stack
trace in the browser.
Can also be set to <tt>:after_handler</tt> to trigger app-specified error
handling before showing a stack trace in the browser.
</dd>
<dt>static</dt>
@ -2223,15 +2225,14 @@ set :protection, :session => true
<dd>Disable when using a server able to do this on its own.</dd>
<dd>Disabling will boost performance.</dd>
<dd>
Enabled per default in classic style, disabled for
modular apps.
Enabled per default in classic style, disabled for modular apps.
</dd>
<dt>static_cache_control</dt>
<dd>
When Sinatra is serving static files, set this to add
<tt>Cache-Control</tt> headers to the responses. Uses the
<tt>cache_control</tt> helper. Disabled by default.
When Sinatra is serving static files, set this to add <tt>Cache-Control</tt>
headers to the responses. Uses the <tt>cache_control</tt> helper. Disabled
by default.
</dd>
<dd>
Use an explicit array when setting multiple values:
@ -2262,13 +2263,12 @@ set :protection, :session => true
## Environments
There are three predefined `environments`: `"development"`,
`"production"` and `"test"`. Environments can be set
through the `RACK_ENV` environment variable. The default value is
`"development"`. In the `"development"` environment all templates are reloaded between
requests, and special `not_found` and `error` handlers
display stack traces in your browser.
In the `"production"` and `"test"` environments, templates are cached by default.
There are three predefined `environments`: `"development"`, `"production"` and
`"test"`. Environments can be set through the `RACK_ENV` environment variable.
The default value is `"development"`. In the `"development"` environment all
templates are reloaded between requests, and special `not_found` and `error`
handlers display stack traces in your browser. In the `"production"` and
`"test"` environments, templates are cached by default.
To run different environments, set the `RACK_ENV` environment variable:
@ -2310,13 +2310,13 @@ end
The `error` handler is invoked any time an exception is raised from a route
block or a filter. But note in development it will only run if you set the
show exceptions option to `:after_handler`.
show exceptions option to `:after_handler`:
```ruby
set :show_exceptions, :after_handler
```
The exception object can be obtained from the `sinatra.error` Rack variable.
The exception object can be obtained from the `sinatra.error` Rack variable:
``` ruby
error do
@ -2449,8 +2449,8 @@ class MyAppTest < Test::Unit::TestCase
end
```
Note: If you are using Sinatra in the modular style, replace `Sinatra::Application`
above with the class name of your app.
Note: If you are using Sinatra in the modular style, replace
`Sinatra::Application` above with the class name of your app.
## Sinatra::Base - Middleware, Libraries, and Modular Apps
@ -2475,8 +2475,8 @@ class MyApp < Sinatra::Base
end
```
The methods available to `Sinatra::Base` subclasses are exactly the same as those
available via the top-level DSL. Most top-level apps can be converted to
The methods available to `Sinatra::Base` subclasses are exactly the same as
those available via the top-level DSL. Most top-level apps can be converted to
`Sinatra::Base` components with two modifications:
* Your file should require `sinatra/base` instead of `sinatra`;
@ -2490,7 +2490,7 @@ including the built-in server. See
[Configuring Settings](http://sinatra.github.com/configuration.html)
for details on available options and their behavior. If you want
behavior more similar to when you define your app at the top level (also
know as Classic style), you
known as Classic style), you
can subclass `Sinatra::Application`.
``` ruby
@ -2508,10 +2508,10 @@ end
Contrary to common belief, there is nothing wrong with the classic style. If it
suits your application, you do not have to switch to a modular application.
The main disadvantage of using the classic style rather than the modular style is that
you will only have one Sinatra application per Ruby process. If you plan to use
more than one, switch to the modular style. There is no reason you cannot mix
the modular and the classic styles.
The main disadvantage of using the classic style rather than the modular style
is that you will only have one Sinatra application per Ruby process. If you
plan to use more than one, switch to the modular style. There is no reason you
cannot mix the modular and the classic styles.
If switching from one style to the other, you should be aware of slightly
different default settings:
@ -2633,9 +2633,9 @@ A `config.ru` file is recommended if:
* You want to use more than one subclass of `Sinatra::Base`.
* You want to use Sinatra only for middleware, and not as an endpoint.
**There is no need to switch to a `config.ru` simply because you
switched to the modular style, and you don't have to use the modular style for running
with a `config.ru`.**
**There is no need to switch to a `config.ru` simply because you switched to
the modular style, and you don't have to use the modular style for running with
a `config.ru`.**
### Using Sinatra as Middleware
@ -2856,9 +2856,9 @@ The following Ruby versions are officially supported:
until the release of Sinatra 2.0.
</dd>
<dt>Ruby 2.0.0</dt>
<dt>Ruby 2.x</dt>
<dd>
2.0.0 is fully supported and recommended. There are currently no plans to drop
2.x is fully supported and recommended. There are currently no plans to drop
official support for it.
</dd>
@ -2889,9 +2889,9 @@ known to run Sinatra:
Not being officially supported means if things only break there and not on a
supported platform, we assume it's not our issue but theirs.
We also run our CI against ruby-head (the upcoming 2.1.0), but we can't
guarantee anything, since it is constantly moving. Expect 2.1.0 to be fully
supported.
We also run our CI against ruby-head (future releases of MRI), but we can't
guarantee anything, since it is constantly moving. Expect upcoming 2.x releases
to be fully supported.
Sinatra should work on any operating system supported by the chosen Ruby
implementation.