Job release-versioning-and-changelog-automated · revised 11 October 2026
Automate version numbers, changelog entries and tagged releases for one repository
A dry run on a test branch shows the next version, a grouped changelog and a tag computed from your commit history. A real release is created once, from the release branch, only after your approval.
You might be seeing
- Version numbers are chosen by feel and sometimes skipped or repeated
- The changelog is written from memory at release time, or not at all
No passwords, keys, card details or admin invites needed to start.
What usually happened
The release process is a manual sequence: pick a number, write notes, tag, publish. Each step depends on one person's memory, the number does not reflect the kind of change, and a repeated or partly failed run can create a duplicate tag or a release without notes. Automation also fails in familiar ways, for example when the checkout holds only the latest commit, so the tool cannot see the history it needs.
Who it’s for: A small team that tags releases by hand, forgets the changelog or argues about the next version number.
Usually starts when: A release went out with the wrong version or an empty changelog, or the person who knows the release steps is unavailable.
The result: On a rehearsal branch, a dry run computes the next version from a set of agreed synthetic commits, produces a grouped changelog entry and names the tag without creating it. From the release branch, an approved run creates exactly one tag and one release record with those notes, and a repeat run with no new changes creates nothing.
Check whether this job fits
Answer about how you merge and release today. These answers decide what the tool can read.
What you get
- A pull request with the release configuration, the pipeline change and a short operator note
- A table of the synthetic commits, the version each should produce and the version the dry run produced
- Links to the dry run, the approved release run and a repeat run that created nothing
- Steps to turn the automation off
Included
- One repository with one release branch and one versioning scheme
- Agree the commit convention, or the pull request title convention if changes are squash merged, and what each type means for the next version
- Configure release automation with a dry-run mode, a changelog grouped by kind of change and one approval step before anything is created
- Make sure the pipeline checks out enough history and tags for the tool to work
- Test with a set of synthetic commits on a rehearsal branch and then one approved release from the release branch
Not included
- Publishing to a package registry or app store, unless agreed in writing and run with your own credentials
- Deploying the release or changing production
- Rewriting past history or renumbering earlier releases
- Writing release notes for your customers beyond the generated changelog
- Legal, licence or compliance text in releases
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
A dry run over the agreed synthetic commits produces the version for each case that the agreed table states, and creates no tag or release.
Evidence: The table of commits, expected and computed versions, and the dry run log.
The changelog entry groups changes by kind and lists each synthetic change once, in a format agreed before work starts.
Evidence: The generated changelog entry.
One approved run from the release branch creates exactly one tag and one release record with those notes, and a repeat run with no new changes creates nothing.
Evidence: Links to the approved run, the repeat run and the list of tags and releases.
Releases cannot be created from any branch other than the release branch, and no package or deployment was published.
Evidence: The pipeline rules in the diff and a run from another branch that created nothing.
Sign-off. You inspect the dry-run table, the approved release and the repeat run, sign off in writing and merge the pull request. Payment follows sign-off.
If it fails. If the computed versions differ from the agreed table or a repeat run creates anything, you do not pay for this fixed scope. If tagging cannot be separated from publishing, we explain the options and stop.
When it fits, and when we stop
It fits when
- The repository has a protected release branch and a maintainer who approves releases
- The team can follow a commit or pull request title convention, or agrees to
- CI can run on the release branch and on a rehearsal branch
- Earlier versions, if any, can be listed so that numbering continues sensibly
We stop and tell you if
- The release must be published with credentials that cannot be held in your CI secret store
- Commit history is unusable and the team will not adopt a convention for new changes
- A real release would trigger a production deploy that cannot be separated from tagging
What could go wrong
Before merge, closing the pull request leaves your repository unchanged. After merge, your maintainer can revert the configuration. A tag and release created during acceptance can be deleted by your maintainer using the note we supply; nothing is published elsewhere.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A wrong version number is created and tags cannot be reused once others depend on them. | The first real release happens only after the dry run matches the agreed table and your approver starts it. |
| A repeated or partly failed run creates a duplicate tag or release. | Acceptance includes a repeat run that must create nothing, and the pipeline is written to skip an existing tag. |
| Tagging triggers a publish or deploy by accident. | We separate tagging from publishing before any rehearsal and stop if they cannot be separated. |
An independent reviewer checks the dry-run table against the agreed rules, that the real release ran only from the release branch after approval and that the repeat run created no duplicate. Your approver controls every real release and your maintainer merges.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the convention, the version rules, the release branch, the approver and the rehearsal branch in writing
- Read the history and the pipeline and note the checkout depth, tags and branch protections
- Configure the release tool with a dry-run mode, a grouped changelog and one approval step
- Fix the checkout so the history and tags are available to the tool
- Run a dry run over synthetic commits and compare the computed versions with the agreed table
- Have your approver start one real release from the release branch, then run again to show nothing new is created, and have an independent reviewer check the runs
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access and necessary permissions are in place. Platform, runner and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
If releases keep needing attention as the repository changes, a monthly rehearsal can run the release dry run and report drift.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Semantic Versioning describes what a major, minor and patch change mean, and Conventional Commits describes a message format that maps onto them. Your team can adopt both without us. www.conventionalcommits.org
- Keep a Changelog describes a human-oriented changelog with grouped sections and dated releases. keepachangelog.com
Questions
Do we have to change how we write commits?
The tool reads a convention, so yes. Where changes are squash merged, the convention can apply to the pull request title instead. We agree it with you first.
Will this publish our package?
No. It tags and records a release. Publishing is excluded unless agreed in writing and run with your own credentials.
What if a release goes out with a wrong number?
A published version cannot be changed, so the fix is a new version. The dry run and the approval step exist to catch it before anything is created.
Send an enquiry
Send us
- How you release today, step by step, and where versions are recorded
- Your branch layout and how changes are merged: merge commits, squash or rebase
- The latest released version and whether earlier tags are consistent
- Do not send credentials, source code or an access invitation in the first enquiry
Later, once you agree
- The repository and pipeline files through an authorised company-controlled route
- The release branch name and the approver for the first real release
- A scratch branch we may use for the dry run
You own the repository, the release branch, the tags and the credentials. We work from authorised files on a branch through a company-controlled identity. Only your approver can start the first real release, and we never receive registry or deploy credentials.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “release-versioning-and-changelog-automated” as the subject.