Pavel LavrukhinandClaude Opus 5
dda7b30fcf
* docs(adr): resolve the A-13 collision, zero-pad numbers and add an index
Two records carried the number A-13:
docs/adr/A-13-expired-gpg-key-handling.md
docs/adr/A-13-screenshot-build-tag.md
An ADR number is a stable identifier, so a duplicate makes every citation
ambiguous. A-13-expired-gpg-key-handling.md keeps the number: it is cited
from docs/commands/recipients.md, docs/usecases/team-workflows.md and
docs/adr/A-14-team-workflows.md. The screenshot record has no inbound
citations and is renumbered to A-15.
Zero-pad A-3 through A-9 to A-03 through A-09 so the directory sorts
correctly now that the set has passed ten entries. None of these has an
inbound citation from another document; the single reference in
internal/backend/storage/fs/rcs.go is updated in this commit.
Add docs/adr/README.md as the index, recording the naming rules, the status
and authoring date of every record, and three facts that are otherwise only
discoverable from git history:
- A-01 and A-02 are cited from the CHANGELOG unreleased section but no file
was ever written for either; the numbers stay reserved.
- The A-13 collision and which record was renumbered.
- SECURITY_AUDIT_REPORT.md and CODE_QUALITY_REPORT.md, cited as the Source
of A-03 through A-10, were removed in 77894053 and are not in the tree.
No record content is changed apart from the H1 lines, which must match the
file names.
Signed-off-by: Pavel Lavrukhin <46395539+dantte-lp@users.noreply.github.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* docs: add docs/conventions.md and adopt Conventional Commits
CONTRIBUTING.md required a bracketed [TAG] prefix on every commit subject.
That has not matched practice for some time: of the 344 commit subjects
since 2025-01-01, 225 are Conventional Commits and 67 use a [TAG]. The
CHANGELOG unreleased section uses a third set including [SECURITY] and
[PKG-BREAK], neither of which CONTRIBUTING.md lists.
Replace the [TAG] rule with Conventional Commits and add
docs/conventions.md as the single normative reference for:
- commit types (a closed list) and the scopes derived from the package
layout, including the five values that appear as types in the history but
are scopes: otp, age, bug, fscopy, openbsd;
- the distinction between a CLI break, which uses "!" and a
BREAKING CHANGE: footer and forces a major release, and a break confined
to pkg/gopass, which uses a PKG-BREAK: footer and does not (ADR A-12);
- Semantic Versioning, and which surfaces it does and does not cover;
- branch and tag names, including the release/ and prep/ prefixes owned by
the release automation;
- file naming for ADRs, documentation and Go sources.
The Developer Certificate of Origin requirement is unchanged. Conventional
Commits governs the subject line and the DCO adds a trailer, so the two are
independent.
Also correct the API Stability section of ARCHITECTURE.md, which still
described pkg/gopass/doc.go as carrying "an explicit instability warning"
and instructed consumers to "treat any pkg/ type or function change as
potentially breaking". Both statements predate ADR A-12: doc.go now
declares the package best-effort stable and permits additive changes in any
release. The section also referred to issue #3414 as an open decision; that
decision is recorded in A-12 with status accepted.
Extend the folder list in AGENTS.md with the five pkg/ directories it does
not mention (otp, passkey, pinentry/cli, protect, qrcon), using each
package's own doc comment as the description.
Signed-off-by: Pavel Lavrukhin <46395539+dantte-lp@users.noreply.github.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
3.1 KiB
Contributing
gopass uses GitHub to manage reviews of pull requests.
-
If you are a new contributor see: Steps to Contribute
-
If you have a trivial fix or improvement, go ahead and create a pull request.
-
If you plan to do something more involved, first raise an issue to discuss your idea. This will avoid unnecessary work.
-
Relevant coding style guidelines are the Go Code Review Comments and the Formatting and style section of Peter Bourgon's Go: Best Practices for Production Environments.
Steps to Contribute
Should you wish to work on an issue, please claim it first by commenting on the GitHub issue you want to work on it. This will prevent duplicated efforts from contributors.
Please check the help-wanted label to find issues that need help.
If you have questions about one of the issues please comment on them and one of the maintainers
will try to clarify it.
Pull Request Checklist
-
Use that latest stable Go release
-
Branch from master and, if needed, rebase to the current master branch before submitting your pull request. If it doesn't merge cleanly with master you will be asked to rebase your changes.
-
Commits should be as small as possible, while ensuring that each commit is correct independently.
-
Add tests relevant to the fixed bug or new feature.
-
Commit messages must contain Developer Certificate of Origin /
Signed-off-byline, for example:One line description of commit More detailed description of commit, if needed. Signed-off-by: Your Name <your@email.com> -
Write every commit subject as a Conventional Commit, for example
fix(age): expand ~/ in age.ssh-key-path. The accepted types and scopes are listed in docs/conventions.md.Conventional Commits governs the subject line; the Developer Certificate of Origin adds a trailer. Both apply to every commit.
-
Write the pull request title as a valid Conventional Commit. Pull requests are squash-merged, so the pull request title is the string that reaches the changelog.
Conventions
Commit messages, versioning, branch and tag names, and file naming are specified in docs/conventions.md. Read it before opening your first pull request.
Building & Testing
- Build via
go buildto create the binary file./gopass. - Run unit tests with:
make test - Run meta tests with:
make codequality - Run integration tests
make test-integration
If any of the above don't work, check the troubleshooting information in the docs directory before opening an issue.
Releasing
See docs/releases.md.
Maintainers preparing release candidates should use signed tags named exactly
vX.Y.Z-rc.N from the merged release/vX.Y.Z-rc.N branch so the GitHub release
automation publishes them as prereleases.