build: release v2.8.2-2

AGENTS.md

@@ -34,7 +34,14 @@ Do not push directly to `main`; all changes must go through pull requests. The r
 
 Use conventional commit subjects, for example `docs: clarify tmpfs logging advice` or `fix: preserve extra imapfilter args`. Every commit should include a body explaining why the change is needed, what changed, and validation performed.
 
-Every change set requires dated changelog entries in `CHANGELOG.md` using the existing standard changelog format. Write entries from the perspective of the final commit or PR, not the sequence of edits in the working session.
+Every change set requires changelog entries in `CHANGELOG.md` written from the perspective of the final commit or PR, not the sequence of edits in the working session.
+When a PR contains multiple distinct user-visible or operator-visible outcomes, split them into separate changelog bullets instead of merging them into one sentence. Keep significant runtime or packaging changes, such as Docker base image changes, separate from automation, CI, documentation, or process-only changes.
+
+The repository's release versioning follows the image tag format already used in git tags, for example `v2.8.2-1` and `v2.8.2-2`, where the upstream `imapfilter` version is combined with a packaging revision suffix. Do not invent unrelated semver such as `1.0.0` unless the repository versioning scheme is intentionally changed everywhere.
+
+Use `Unreleased` only for changes that are not yet tagged. Before or while cutting a release tag, convert the relevant `Unreleased` entries into a versioned section whose heading exactly matches the tag being created, for example `## [v2.8.2-2] - 2026-05-22`. After tagging, `CHANGELOG.md` must contain an entry for that exact released version so users can immediately find it.
+
+If `main` already contains a release tag, ensure the changelog has a matching versioned section for that tag rather than leaving released work under `Unreleased`. A PR should normally add one final changelog entry for its own outcome, and a release PR should not also leave those same changes duplicated under `Unreleased`.
 
 PRs should include a summary, validation commands, documentation updates, linked issues when available, and release-impact notes for environment variables, image tags, or GitHub Actions publishing.
 

CHANGELOG.md

@@ -4,7 +4,15 @@ All notable changes to this project will be documented in this file.
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
-## [Unreleased]
+## [v2.8.2-2] - 2026-05-22
+
+### Changed
+
+- Added a Renovate configuration for grouped GitHub Actions updates with a 30-day minimum release age.
+- Pinned the Dockerfile base image to Alpine `3.23` so future releases can deliberately adopt new Alpine `3.x` minor versions.
+- Documented the Renovate maintenance workflow and its scope for developers.
+
+## [v2.8.2-1] - 2026-05-18
 
 ### Changed
 

Dockerfile

@@ -1,4 +1,4 @@
-FROM alpine:3
+FROM alpine:3.23
 
 ARG IMAPFILTER_CONFIG=/config
 ARG IMAPFILTER_LOGS=/logs

README.md

@@ -53,7 +53,7 @@ The `Makefile` uses Docker by default. To use Podman or another compatible comma
 $ make BUILD_CMD=podman build
 ```
 
-The image is built on Alpine `3` and installs `imapfilter` from Alpine `edge/testing`, because `imapfilter` is not currently available in the stable Alpine repositories.
+The image is built on Alpine `3.23` and installs `imapfilter` from Alpine `edge/testing`, because `imapfilter` is not currently available in the stable Alpine repositories.
 
 Run the container validation suite with `dgoss`:
 
@@ -90,6 +90,33 @@ After changing the packaged `imapfilter` version, update the version file from t
 $ make update-version
 ```
 
+## For developers
+
+### Renovate configuration
+
+The repository Renovate config lives in `renovate.json`.
+
+Its current scope is intentionally narrow:
+
+- GitHub Actions updates from `.github/workflows/main.yml`
+- Dockerfile base image updates for `FROM alpine:3.23`
+
+The current configuration is supposed to behave like this:
+
+- Renovate is enabled only for the `github-actions` and `dockerfile` managers.
+- GitHub Actions updates are grouped into a single pull request named `github actions`.
+- GitHub Actions releases must be at least 30 days old before Renovate proposes them.
+- Alpine base image updates follow the `major.minor` precision in the Dockerfile, so the expected Dockerfile update is a minor-line change such as `alpine:3.23` to `alpine:3.24`.
+- Renovate should not widen the Alpine tag to a patch release such as `3.23.4`.
+- Renovate should not propose Alpine `4.x` updates.
+
+The configuration is not intended to:
+
+- manage `IMAPFILTER_VERSION`
+- update packages installed inside the Docker image
+- automate repository release tags or packaging revision bumps
+- scan other file types or dependency managers in this repository
+
 ## imapfilter resources
 
 These are some resources I found useful for writing imapfilter rules:

renovate.json

@@ -0,0 +1,19 @@
+{
+  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
+  "extends": [
+    "config:recommended"
+  ],
+  "enabledManagers": [
+    "github-actions",
+    "dockerfile"
+  ],
+  "packageRules": [
+    {
+      "matchManagers": [
+        "github-actions"
+      ],
+      "groupName": "github actions",
+      "minimumReleaseAge": "30 days"
+    }
+  ]
+}