The `cleanup` flag is only available on [dpl v2] which is opt-in. Moreover, dpl v2 defaults to `cleanup: false` anyway so there is no need to specify it.
[dpl v2]: https://docs.travis-ci.com/user/deployment-v2
cc #224
* Add an off-by-default 'unstable' flag
* Remove explicit web framework feature names
Having forgotten that deps and features can't have the same name,
attempts to better document all the features in one place were
misplaced.
* Split up tests on Travis
`cargo test` doesn't allow `--workspace` and `--features`
simultaneously, so we're forced to test each package separately in order
to manually specify features (or in this case, test everything but
unstable)
* Update Travis Config
- Document the state of Cargo workspaces and features
- Update the benchmarks to trickle down the 'unstable' feature
Multiple versions of the maud base crate get built, so compiletest
doesn't know which one to use in the same way that cargo would.
A possible solution is to build a canonical version of the crate first
(no features) and then explicitly run the compiletest tests. After, we
run builds and tests as normal, excluding the compiletest tests.
After fiddling around with zero-allocation solutions, I concluded that
all non-allocating approaches are too annoying to work with in realistic
code. Using closures leads to yak-shaving with lifetimes; and because
Iron needs to take ownership of the response body we often end up
cloning the input data anyway.
Removing this constraint has let me simplify the entire system, removing
a net 300 lines from the library. The `html!` macro no longer takes a
writer, and instead returns a `PreEscaped<String>`. This means that the
result of an `html!` can be spliced directly into another `html!`,
removing the need for the `impl Template` rigmarole.
To rub it in, benchmarks show the new code is in fact *faster* than it
was before. How lovely.
