Add release process documents

Author: ingydotnet

Adopters.md

@@ -0,0 +1,55 @@
+# Adopters
+
+Known consumers of libyaml.
+If your project uses libyaml, please open a PR to add it.
+
+## Tier 1 -- Direct consumers with major downstream impact
+
+These projects account for the vast majority of libyaml's real-world
+exposure.
+They are notified in advance of security releases.
+
+- **[PyYAML](https://github.com/yaml/pyyaml)** -- Python YAML
+  library.
+  The `_yaml` C extension wraps libyaml; PyPI wheels bundle it
+  statically.
+  Downstream: Ansible, AWS CLI, Kubernetes client tooling, Home
+  Assistant, SaltStack, Jupyter.
+
+- **[Ruby Psych](https://github.com/ruby/psych)** -- Ruby's default
+  YAML parser, ships with Ruby.
+  Downstream: Rails, Jekyll, Bundler, RubyGems, Chef, Puppet.
+
+## Tier 2 -- Linux distributions
+
+Distribution packages are coordinated via established infrastructure:
+
+- **Debian / Ubuntu** -- `libyaml-0-2`, `libyaml-dev`
+- **Fedora / RHEL** -- `libyaml`, `libyaml-devel`
+- **Alpine** -- `yaml`, `yaml-dev`
+- **Arch** -- `libyaml`
+- **SUSE / openSUSE** -- `libyaml-0-2`, `libyaml-devel`
+
+For embargoed security issues, we use
+[distros@openwall.org](https://oss-security.openwall.org/wiki/mailing-lists/distros).
+
+## Tier 3 -- Other language bindings
+
+- **[YAML::XS](https://metacpan.org/pod/YAML::XS)** -- Perl
+- **[lyaml](https://github.com/gvvaughan/lyaml)** -- Lua
+- **[yaml](https://cran.r-project.org/package=yaml)** -- R
+- **[yaml](https://www.php.net/manual/en/book.yaml.php)** -- PHP
+  extension
+- **[yamerl](https://github.com/yakaz/yamerl)** -- Erlang
+- **[libyaml-safer](https://github.com/simonask/libyaml-safer)** --
+  Rust
+- **[HsYAML](https://hackage.haskell.org/package/HsYAML)** -- Haskell
+
+## Tier 4 -- Transitive consumers
+
+These projects use libyaml through one of the above bindings.
+They are not coordinated with directly but benefit from upstream
+releases:
+
+Ansible, AWS CLI, Kubernetes ecosystem, Rails, Jekyll, Chef, Puppet,
+SaltStack, Home Assistant, MkDocs, Jupyter, and many more.

Releasing.md

@@ -0,0 +1,96 @@
+# Releasing libyaml
+
+## Version numbering
+
+libyaml follows `MAJOR.MINOR.PATCH` versioning.
+Patch releases contain bug fixes and security fixes only.
+
+## Pre-release checklist
+
+- [ ] All CI checks pass on the release branch
+- [ ] Security advisories drafted for any fixes (see below)
+- [ ] Downstream maintainers notified (see Downstream coordination)
+
+## Update version numbers
+
+Update the version in these files:
+
+- `announcement.msg`
+- `Changes` (add release entry with date)
+- `CMakeLists.txt` (`YAML_VERSION_MAJOR`, `YAML_VERSION_MINOR`,
+  `YAML_VERSION_PATCH`)
+- `configure.ac` (`YAML_MAJOR`, `YAML_MINOR`, `YAML_PATCH`,
+  `YAML_RELEASE`, `YAML_CURRENT`, `YAML_REVISION`)
+
+Commit and push to `release/0.x.y`.
+
+## Build release archives
+
+The GitHub workflow `.github/workflows/dist.yaml` builds archives
+automatically when you push to a `release/*` branch.
+It produces `yaml-0.x.y.tar.gz` and `yaml-0.x.y.zip`.
+
+To build manually:
+
+    make docker-dist
+
+Archives are written to `pkg/docker/output/`.
+This requires the `yamlio/libyaml-dev` Docker image (build it with
+`make docker-build`).
+
+## Merge and tag
+
+    git checkout master
+    git merge release/0.x.y
+    git tag -a 0.x.y
+    # Paste the Changes entry as the tag message
+    git push origin master 0.x.y
+
+## Create a GitHub release
+
+1. Go to Releases and click "Draft a new release"
+2. Select the tag you just created
+3. Title: `v0.x.y`
+4. Paste the changelog entry into the description
+5. Upload the `.tar.gz` and `.zip` archives
+6. Generate SHA-256 checksums and include them in the release notes
+7. Publish
+
+## Security release process
+
+For releases that fix security vulnerabilities:
+
+### Before the release
+
+1. Draft a GitHub Security Advisory (GHSA) for each vulnerability
+   via the Security tab
+2. Request a CVE ID through GitHub (they are a CNA)
+3. Set the patched version in the advisory
+4. Notify Tier 1 downstream maintainers listed in `Adopters.md`
+   so they can prepare updated packages
+
+### On release day
+
+1. Publish all drafted GHSAs
+2. Push the signed tag and publish the GitHub release
+3. Post to `oss-security@lists.openwall.org`
+
+### After the release
+
+1. Monitor downstream releases (PyYAML wheels, Ruby, distro packages)
+2. Update GHSAs with downstream advisory references as they appear
+
+## Downstream coordination
+
+For security releases, notify downstream maintainers before
+publishing:
+
+- **Tier 1** (direct consumers, pre-notify): PyYAML, Ruby Psych
+- **Tier 2** (distros): `distros@openwall.org` for embargoed issues
+- **Tier 3** (other bindings): public announcement on release day
+
+See `Adopters.md` for the full list.
+
+## Update pyyaml.org
+
+See <https://github.com/yaml/pyyaml.org/blob/master/ReadMe.md>.

Security.md

@@ -0,0 +1,32 @@
+# Security Policy
+
+## Supported Versions
+
+| Version | Supported |
+|---------|-----------|
+| 0.2.x   | Yes       |
+| < 0.2   | No        |
+
+## Reporting a Vulnerability
+
+To report a security vulnerability, please use
+[GitHub's private vulnerability reporting](https://github.com/yaml/libyaml/security/advisories/new).
+
+Do **not** open a public issue for security vulnerabilities.
+
+We will acknowledge your report within 7 days and aim to release a
+fix within 30 days for confirmed vulnerabilities.
+
+## Coordinated Disclosure
+
+For vulnerabilities affecting downstream consumers (PyYAML, Ruby
+Psych, etc.), we coordinate disclosure with affected maintainers
+before public release.
+Downstream maintainers who want to be included in pre-release
+notifications can contact the maintainers privately.
+
+## Security Advisories
+
+Published advisories are listed on the
+[Security Advisories](https://github.com/yaml/libyaml/security/advisories)
+page.