Community & Maintainer Guide

Branching strategy

main — always releasable; direct commits are not permitted
Feature branches — branch from main, open a PR, require at least one review and green CI before merge
Release branches are not used; releases are cut directly from main

All PRs must pass the required status checks defined in .github/workflows/pr-checks.yml
Reviewers should check for correctness, test coverage, documentation completeness, and adherence to the TypeScript conventions described in the README
Keep PRs focused — one concern per PR

This project follows Keep a Changelog conventions.

All changes go into the [Unreleased] section as they are merged
Use the standard subsections — add only those that have entries:
- Added — new features
- Changed — changes to existing behaviour
- Deprecated — features that will be removed in a future release
- Removed — features removed in this release
- Fixed — bug fixes
- Security — vulnerability fixes
Write entries from the user's perspective, not the implementer's — describe what changed in behaviour, not which files were touched
Each entry should be a single line; link to the relevant PR where helpful (e.g. - Added X ([#42](https://github.com/ConfiguredThings/RDP.js/pull/42)))
Do not add entries for internal refactors, test changes, or CI updates that have no effect on consumers of the package

At release time the [Unreleased] section is moved to a versioned section — see Cutting a release below.

Ensure main is green and all intended changes are merged
Update CHANGELOG.md: rename [Unreleased] to [X.Y.Z] - YYYY-MM-DD, add a fresh empty [Unreleased] section above it, and update the comparison links at the bottom
Bump the version in package.json following Semantic Versioning
Commit: chore: release vX.Y.Z
Tag: git tag vX.Y.Z && git push --tags
Run npm publish from a clean working directory (the prepublishOnly script enforces this)