Tags, Signed Releases, Semantic Versioning, Changelogs, and Support Lines: Configuration, Design Choices, and Tradeoffs

1. Release policy begins where tag syntax ends

Git can create a tag named v1.4.0, sign it, and push it. Git cannot decide whether the software has a stable public API, whether the change is breaking, who is authorized to release, how long version 1.4 is supported, or which fixes must be backported. Those decisions belong to project/release governance.

2. Signing configuration: separate backend, key selection, and verification trust

git config --show-origin --show-scope --get gpg.format
git config --show-origin --show-scope --get user.signingKey
git config --show-origin --show-scope --get tag.gpgSign

Current Git defaults gpg.format to openpgp; supported alternatives include x509 and ssh. user.signingKey selects the signing identity/key for tag/commit signing when automatic selection is unsuitable. tag.gpgSign=true requests signing of tags by default.

3. OpenPGP, X.509, and SSH are different trust ecosystems

Format choice is infrastructure policy. Do not turn on tag.gpgSign globally before verifying that every repository and automation environment has the required key access and non-interactive signing behavior.

4. SSH signing illustrates validity versus trust explicitly

For SSH verification, Git can use gpg.ssh.allowedSignersFile to map trusted principals to public keys. Current Git distinguishes a cryptographically valid signature from one whose key is trusted by that configuration. This is an important model for every signing backend: “signature math passed” and “our release policy trusts this identity” are separate questions.

5. Decide whether signing should be explicit or defaulted

6. Choose one version/tag naming rule and make automation parse it explicitly

Examples include v1.2.3, release/1.2.3, or product-prefixed tags such as api-v1.2.3. The choice should optimize unambiguous automation, not aesthetics. Document pre-release conventions such as v2.0.0-rc.1 and whether build metadata appears in tags.

Remember: SemVer itself describes version precedence/meaning around a public API; a Git prefix or product namespace is repository naming policy.

7. Use SemVer only when its public-API model fits

Semantic Versioning is strong when consumers need compatibility promises around a public API. It can be awkward for internal deployment snapshots, data pipelines, continuously deployed services with no versioned consumer API, or products whose compatibility boundary is not represented by one package API.

If SemVer does not fit, choose another documented versioning scheme rather than incrementing MAJOR/MINOR/PATCH mechanically. Git tags can carry any valid ref name; the release convention defines meaning.

8. Support-branch names should express the maintenance promise

Examples such as support/1.4 or release/2026.08 can communicate the maintained line. Define:

• how a support branch is created—from which released tag;
• which bug/security classes qualify for backport;
• whether fixes are developed on trunk then backported, or developed on oldest line then merged/forward-ported;
• how conflicts are reviewed/tested;
• when the line reaches end of support.

9. Backport policy must account for new commit IDs

A cherry-picked fix on support/1.0 is not the same commit object as the original fix on trunk. Preserve the relationship in issue/review/release records and test each support-line result. “Same patch intent” does not guarantee identical behavior against an older codebase.

10. Changelog generation should start from release questions, not command availability

A production pipeline can combine these sources but should retain human review for externally meaningful release notes.

11. Release-ref protection is server governance

Core Git permits local tag deletion/replacement. A hosting/server platform can restrict who creates/deletes/updates release tags or require signed objects. Those controls are not portable Git objects. This course describes the Git facts; GitHub/GitLab/Azure-specific configuration belongs in their platform courses.

12. Configuration scope and precedence

git config --list --show-origin --show-scope | grep -E '(tag\.gpgSign|user\.signingKey|gpg\.format|push\.followTags)'

Signing-key paths and agent availability are machine/user concerns, while a repository may define stricter release defaults. CI may inject configuration/environment at runtime. Inspect the effective value on the exact release runner rather than assuming a developer workstation configuration is reproduced there.

13. Decision table — a small library with two supported lines

14. Knowledge check

15. Summary

Release configuration should make signing/key/trust behavior explicit, version names predictable, support-line maintenance testable, and published tag immutability enforceable. Git supplies refs and signatures; release semantics and authorization come from project/server policy.

Authoritative references

• git-config
• git-tag
• gitformat-signature
• Semantic Versioning 2.0.0