padrino: a Sinatra superset whose readme is RDoc, so its badges never render on GitHub

The readme is RDoc, so the four badges above the title do not render

The file is named README.rdoc and written in RDoc, not Markdown, which has a visible consequence. The four badges at the top are RDoc image macros, an image syntax followed by a bracketed link, wrapped in the same macro form:

{rdoc-image:https://github.com/padrino/padrino-framework/actions/workflows/ci.yml/badge.svg?branch=master}[https://github.com/padrino/padrino-framework/actions/workflows/ci.yml]
{rdoc-image:https://api.codeclimate.com/v1/badges/900d6e424498f0e2b7ff/maintainability}[https://codeclimate.com/github/padrino/padrino-framework/maintainability]

That syntax is understood by the documentation generator, which is where the CI badge, the maintainability score and the chat badge are actually meant to be read. GitHub does not interpret RDoc macros, so on the repository page those lines appear as literal text rather than as images, which is why the repository looks badge-less when it plainly is not. The headings follow the same convention, with equals signs for levels, and the inline links use braces around the label and brackets around the target.

The copyright line stops at 2016 and the last commit is from June 2026

The closing section reads Copyright Padrino, with the year range written as 2010 to 2016, and points at a licence file for details. The default branch, however, received a push on 2026-06-22, so the code has moved a decade past the last year anyone updated the notice. That is a cosmetic problem in the general case and a slightly more interesting one here, because the licences of the individual components are the part people check when they are deciding whether a component can be vendored into an existing Sinatra application. The tree does carry a licence file at the root and a permissively known licence in its metadata, so the terms are findable; it is the attribution line that has not been touched. A submodule file is present too, so parts of the repository come from elsewhere.

Eight sub-gems ship in the tree and one has no feature entry

The installation section says one command installs the necessary gems, and the tree shows what that means: a directory for the framework itself plus eight named components, covering the core, an admin interface, caching, generators, helpers, a mailer, support code, and a performance component. The readme's feature list is a list of fourteen capabilities and each maps to one of those directories, with two exceptions worth noticing. The performance component has no entry in that list, so a component that ships in every install is undocumented in the overview. And the mapping runs the other way for the admin interface, which is described by comparison to another framework's built-in admin rather than by what it does.

The readme is a list of links, and the support channel is a chat room

Counted properly, the file contains one runnable command and a great many pointers. The command is gem install padrino. Everything else is a link: the installation guide, the guide on using the components inside an existing Sinatra project, an overview of how the two fit together, a step by step blog tutorial, generated API documentation, a quick overview of the generation commands, a page arguing why one would choose this framework, a channel link, and the issue tracker. The further questions section exists solely to point at that channel. So the readme answers the question it is asked most often, which is whether to use it, by referring you elsewhere, and the community links are a chat room badge and a code triage badge rather than anything a maintainer controls.

Documentation links are plain http, with two spellings of the same domain

Every URL in the file uses the unencrypted scheme, and the project's own domain appears in two forms. The header writes the site with a www prefix and an unprefixed link, the homepage field in the metadata uses the www form, and the body links use the bare domain without www. The related projects are the same: the Sinatra site with www, the generated documentation with www. Any of these links that has not been rewritten will redirect, and a reader following the older ones pays for it. The chat link, the code triage badge and the issue tracker are the exceptions that use the encrypted scheme. It is the kind of inconsistency that survives because the links still work, which is exactly why it survives.

No Ruby version is stated, although bug reports are asked for one

The prerequisites section does not exist. The file says to install from the package index, mentions that the individual components can be pulled into an existing Sinatra application, and points at an installation guide for details. Nowhere in it is there a Ruby version, a Sinatra version, or a Rack version. Then the bug reporting section asks for exactly those: be sure to include all relevant information, like the versions of Padrino, Rack, Sinatra, Ruby and operating system you are using, and it asks for a minimal project with a lock file. So the project treats the interpreter and library matrix as the first thing a reporter should supply, and publishes none of it in the place a new user would look. The type checker configuration, the linter configuration and the documentation options are all present in the tree, so the information exists somewhere; it is simply not in the readme.

The metadata says full-stack and the readme says superset

The two descriptions of the project differ in emphasis rather than in fact. The project description calls it a full-stack Ruby framework built upon Sinatra. The readme calls it a framework that tries to make it as fun and easy as possible to code more advanced web applications by building upon the Sinatra philosophies, and states plainly that Padrino is simply a superset of existing Sinatra functionality, and that to use it you should already be familiar with Sinatra. The stated motivation is that people like Sinatra's simplicity and then miss what larger frameworks provide when the application stops being trivial, so the goal is a standard library of tools that keeps the Sinatra feel. Each comparison in the feature list points at the same comparison: a mailer likened to a component of one large framework, an admin interface likened to another's.

Editorial conclusion

Use it when the shape of the problem is one Sinatra application that has outgrown Sinatra, and when you want the Rails-shaped pieces without adopting Rails. Three things to check first. The framework's own framing is a superset with individually installable components, so the cost of saying yes is smaller than the metadata word full-stack suggests, and the mountability it claims as its differentiator is the part with no competitor claim attached. Second, there is no documented Ruby version anywhere in the readme, while the bug reporting instructions ask you to state your Ruby version, so find the supported range yourself before you pin a deployment. Third, the readme is almost entirely pointers to an external site, which means the code and the prose have aged at different speeds and the prose you will actually read is not in the repository.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. padrino/padrino-framework on GitHub
4. Project website
5. README