- Please see GOVERNANCE.md for high-level information.
- This library is meant to do 1 thing only (and must to it well), so we should limit new features beyond the "scaffolding of API endpoint handlers" to the minimum possible.
- There is no direct pushing to
main
branch. Any change must go through a Pull Request. This applies to all contributor roles. This includes typo updates and other such one-liner fixes. - Code Coverage on the default branch (
main
) must always be 100%. - Any added feature or bugfix must be proven to work on all 4 runtimes (Deno, Cloudflare Workers, Bun, and Node.js)
- Publishing into the JavaScript Registry may only happen via git tags. A GitHub Action has been set up to automate publishing when a new tag is created on (or pushed to) remote.
- Only tag official releases on
main
branch. In other words: the tagged commit must exist on themain
branch. - Our git tags must always have the format
vX.Y.Z
: starting with the letterv
in lowercase, followed byX.Y.Z
which conforms to the SemVer standard where X = major, Y = minor, and Z = patch. - Don't forget to update the library version in the
jsr.json
file before tagging your commit for release, otherwise the release won't happen. Heads up: the value injsr.json
file starts with the major version directly (without the letterv
)- In the future, a tool such as semantic-release might be used to automate version bumps.
- Before publishing an "official release", it's always advisable to publish an
"alpha release" first. For example, if you're working on the feature "foo",
for which you branched off from
main
at the most recent git tagv1.5.1
, then tagging your commitv1.5.1-foo-alpha.1
would be an appropriate choice.