Merge pull request 'Release v1.1.1 — forget reliability fixes' (#42)

CHANGELOG.md

@@ -6,6 +6,23 @@ and the project follows [Semantic Versioning](https://semver.org/).
 
 ## [Unreleased]
 
+## [1.1.1] - 2026-08-22
+
+### Fixed
+
+- Prevented agents from panicking when a WebSocket connection ends. The
+  WebSocket library transfers ownership of a successful upgrade stream to
+  the connection and leaves the HTTP response body nil; attempting to close
+  that body caused agents to restart and left forget jobs permanently stuck
+  in `running`. ([#37])
+- Manual forget jobs now receive the same per-source-group retention policies
+  as scheduled forget jobs. The API also supports a validated `--dry-run`
+  option through the complete server-to-agent-to-restic path, and rejects
+  hosts without configured retention before creating a job. ([#36])
+- Corrected the admin-credentials help text to reflect that forget uses normal
+  append-only credentials and blank admin credentials do not provide a
+  fallback for prune. ([#34])
+
 ## [1.1.0] - 2026-06-15
 
 ### Added
@@ -123,5 +140,11 @@ with a web UI, JSON API, and self-updating agent fleet.
   go vet, golangci-lint).
 - Threat model published (`docs/threat-model.md`).
 
-[Unreleased]: https://gitea.dcglab.co.uk/steve/restic-manager/compare/v1.0.0...HEAD
+[Unreleased]: https://gitea.dcglab.co.uk/steve/restic-manager/compare/v1.1.1...HEAD
+[1.1.1]: https://gitea.dcglab.co.uk/steve/restic-manager/compare/v1.1.0...v1.1.1
+[1.1.0]: https://gitea.dcglab.co.uk/steve/restic-manager/releases/tag/v1.1.0
 [1.0.0]: https://gitea.dcglab.co.uk/steve/restic-manager/releases/tag/v1.0.0
+
+[#37]: https://gitea.dcglab.co.uk/steve/restic-manager/issues/37
+[#36]: https://gitea.dcglab.co.uk/steve/restic-manager/issues/36
+[#34]: https://gitea.dcglab.co.uk/steve/restic-manager/issues/34

CONTRIBUTING.md

@@ -2,7 +2,8 @@
 
 Thanks for your interest in restic-manager. This document covers how
 to set up a development environment, the conventions the project
-follows, and how patches make it from your machine into `main`.
+follows, and how to contribute through issues as well as patches that
+make it from your machine into `main`.
 
 ## Project status and scope
 
@@ -108,6 +109,32 @@ admin user.
 
 ## Workflow
 
+### Opening an issue
+
+Issues are contributions too. Use them to report a bug, suggest a
+feature, improve the documentation, or start a design discussion even
+if you do not plan to submit a patch.
+
+Before opening one, search the existing issues and check `tasks.md` to
+see whether the topic is already tracked. Then choose the closest issue
+template:
+
+- [Bug report](./.gitea/issue_template/bug_report.md) for behaviour that
+  does not match the documentation or expected operation.
+- [Feature request](./.gitea/issue_template/feature_request.md) for a new
+  capability or a change to existing behaviour.
+
+Give the issue a specific title, keep it to one problem or proposal,
+and complete the relevant template fields. If no template is an exact
+fit, open a regular issue and explain the context, desired outcome, and
+any alternatives you have considered. Maintainers may ask follow-up
+questions or close requests that duplicate existing work or fall
+outside the project's scope.
+
+Security-sensitive reports are the exception: follow the
+[SECURITY.md](./SECURITY.md) disclosure process and do not open a public
+issue.
+
 ### Before opening a PR
 
 1. **Open an issue first** for non-trivial changes. The design is
@@ -136,25 +163,24 @@ The PR template asks for:
 
 ### Reporting bugs
 
-Open an issue with:
+Use the bug report issue template and include:
 
 - restic-manager version (`server --version`) and agent version.
 - restic version on the affected host.
 - Steps to reproduce.
 - Server and agent logs (sanitise any tokens before pasting).
 
-Security-sensitive bugs go through the [SECURITY.md](./SECURITY.md)
-disclosure path instead — please don't open a public issue for
-them.
+For security-sensitive bugs, use the private disclosure process noted
+above.
 
 ### Suggesting features
 
-Open an issue describing the use case (not just the proposed
-solution). The roadmap in `tasks.md` shows where the project is
-heading; if the suggestion fits a future phase we'll wire it in
-there. If it falls outside the project's scope (multi-tenancy, SaaS,
-non-restic backends — see `spec.md` §2 non-goals) we'll say so
-early to save your time.
+Use the feature request issue template and describe the use case (not
+just the proposed solution). The roadmap in `tasks.md` shows where the
+project is heading; if the suggestion fits a future phase we'll wire it
+in there. If it falls outside the project's scope (multi-tenancy, SaaS,
+non-restic backends — see `spec.md` §2 non-goals) we'll say so early to
+save your time.
 
 ## Code of conduct