143091eb3f
Servant supports defining the same route multiple times with different content-types and result-types, but servant-docs was only documenting the first of copy of such duplicated routes. It now combines the documentation from all the copies. Unfortunately, it is not yet possible for the documentation to specify multiple status codes. |
||
|---|---|---|
| doc | ||
| nix | ||
| servant | ||
| servant-client | ||
| servant-client-core | ||
| servant-client-ghcjs | ||
| servant-docs | ||
| servant-foreign | ||
| servant-server | ||
| .gitignore | ||
| .stylish-haskell.yaml | ||
| .travis.yml | ||
| cabal.make-travis-yml | ||
| cabal.project | ||
| CONTRIBUTING.md | ||
| hlint.yaml | ||
| README.md | ||
| servant.png | ||
| sources.txt | ||
| stack.yaml | ||
servant - A Type-Level Web DSL
Getting Started
We have a tutorial that introduces the core features of servant. After this article, you should be able to write your first servant webservices, learning the rest from the haddocks' examples.
The central documentation can be found here. Other blog posts, videos and slides can be found on the website.
If you need help, drop by the IRC channel (#servant on freenode) or mailing list.
Version history
This table lists the versions of some servant- libraries at the point of
release of servant package.
| 0.10 | 0.11 | 0.12 | |
|---|---|---|---|
| servant | 0.10 | 0.11 | 0.12 |
| servant-blaze | 0.7.1 | ? | ? |
| servant-cassava | 0.7 | ? | ? |
| servant-client | 0.10 | 0.11 | 0.12 |
| servant-docs | 0.10 | 0.11 | 0.11.1 |
| servant-foreign | 0.10 | 0.10.0.1 | 0.10.2 |
| servant-js | 0.9.1 | ? | ? |
| servant-lucid | 0.7.1 | ? | ? |
| servant-mock | 0.8.1.1 | ? | ? |
| servant-server | 0.10 | 0.11 | 0.12 |
| servant-swagger | 1.1.2.1 | ? | ? |
Contributing
See CONTRIBUTING.md
Release process outline (by phadej)
- Update changelog and bump versions in
mastergit log --oneline v0.12.. | grep 'Merge pull request'is a good starting point (use correct previous release tag)
- Create a release branch, e.g.
release-0.13, and protect it from accidental force pushes.- Release branch is useful for backporting fixes from
master
- Release branch is useful for backporting fixes from
- Smoke test in
servant-universegit submodule foreach git checkout masterandgit submodule foreach git pullto get newest of everything.cabal new-build --enable-tests allto verify that everything builds, andcabal new-test allto run tests- It's a good idea to separate these steps, as tests often pass, if they compile :)
- See
cabal.projectto selectivelyallow-newer - If some packages are broken, on your discretisation there are two options:
- Fix them and make PRs: it's good idea to test against older
servantversion too. - Temporarily comment out broken package
- Fix them and make PRs: it's good idea to test against older
- If you make a commit for
servant-universe, you can use it as submodule in private projects to test even more
- When ripples are cleared out:
git tag -sthe releasegit push --tagscabal sdistandcabal upload
travis
.travis.yml is generated using make-travis-yml tool, in
multi-ghc-travis repository.
To regenerate the script use (note: atm you need to comment doc/cookbook/ packages).
runghc ~/Documents/other-haskell/multi-ghc-travis/make_travis_yml_2.hs regenerate
In case Travis jobs fail due failing build of dependency, you can temporarily
add constraints to the cabal.project, and regenerate the .travis.yml.
For example, the following will disallow single troublemaker-13.37 package version:
constraints:
troublemaker <13.37 && > 13.37