9 releases (5 breaking)

0.10.0 Apr 9, 2024
0.9.3 Apr 9, 2024
0.9.2 Oct 10, 2023
0.9.0 Sep 29, 2023
0.5.0 Dec 19, 2022

#274 in Parser implementations

Download history 9428/week @ 2024-01-23 11239/week @ 2024-01-30 9189/week @ 2024-02-06 8246/week @ 2024-02-13 8803/week @ 2024-02-20 8349/week @ 2024-02-27 8283/week @ 2024-03-05 10834/week @ 2024-03-12 7218/week @ 2024-03-19 9716/week @ 2024-03-26 11343/week @ 2024-04-02 15696/week @ 2024-04-09 8883/week @ 2024-04-16 7162/week @ 2024-04-23 3471/week @ 2024-04-30 6919/week @ 2024-05-07

30,730 downloads per month
Used in 9 crates (6 directly)

MIT license

54KB
1K SLoC

The wasmer.toml Format

Continuous Integration

(API Docs)

A parser for the wasmer.toml file used by Wasmer.

For Developers

Releasing

This repository uses Release Please to automate a lot of the work around creating releases.

Every time a commit following the Conventional Commit Style is merged into main, the release-please.yml workflow will run and update the "Release PR" to reflect the new changes.

For commits that just fix bugs (i.e. the message starts with "fix: "), the associated crate will receive a changelog entry and a patch version bump. Similarly, adding a new feature (i.e. "feat:") does a minor version bump and adding breaking changes (i.e. "fix!:" or "feat!:") will result in a major version bump.

When the release PR is merged, the updated changelogs and bumped version numbers will be merged into the main branch, the release-please.yml workflow will automatically generate GitHub Releases, and CI will publish the crate if necessary.

TL;DR:

  1. Use Conventional Commit Messages whenever you make a noteworthy change
  2. Merge the release PR when ready to release
  3. Let the automation do everything else

License

This project is licensed under the MIT license (LICENSE or http://opensource.org/licenses/MIT).

It is recommended to always use cargo crev to verify the trustworthiness of each of your dependencies, including this one.

Dependencies

~4.5MB
~92K SLoC