Master

Planning a release as a document

A release is not a moment of decision, it is a plan written before the moment. The plan names the version, the artifacts, the checks, and the order of the steps, so the release itself is reading a list rather than choosing under pressure. Everything that makes a release late at night is removed by writing it down in advance.

What you will see

The abort path - the line that makes a failed release a non-release rather than a bad one.

About 1 min of reading

Try It

Write the gates.

1

The list

gates = ['tests green', 'changelog written', 'tag pushed', 'lock committed', 'eval >= 0.75'] print(gates)

Before you run it, say out loud what it will print. Then open the answer.

What it prints
Five gates. A release is this list passing, and each one is a claim that can be checked.
2

The abort

print('if any gate fails: stop, do not publish, note the failure in the plan file')

Before you run it, say out loud what it will print. Then open the answer.

What it prints
The abort path - the line that makes a failed release a non-release rather than a bad one.

Data Flow

A plan becomes a release.
1 Decide the version
↓
2 List the gates in order
↓
3 Run them
↓
4 Ship or abort
Line by line

Read the first example one line at a time. A line that prints shows what appears on screen; the rest set things up quietly.

gates = ['tests green', 'changelog written', 'tag pushed', 'lock committed', 'eval >= 0.75'] sets nothing on screen
print(gates) Five gates. A release is this list passing, and each one is a claim that can be checked.
Why this works
Write the abort

The plan says what to do if a gate fails. A release with no abort path is a release where a failure is handled by improvising, which is where a bad version gets shipped.

Keep the plan in the repo

The plan for a release is a file in the branch. Six months later, the reason a version was cut is in that file, and it is the only place that answer survives.

Examples

Name the version first

The version number is decided before the work starts, and the work is then done against it. Deciding after is where a number gets chosen to fit what happened, which is the version that carries no meaning.

List the gates

The checks that must pass: tests green, changelog written, tag on remote, lock committed, eval score acceptable. A release is the list passing, and the list is what makes 'we shipped' a verifiable claim.

Order the steps

Build, test, tag, publish, announce. The order matters, because publishing before tagging means an artifact with no reference, and an announcement before a build is a lie.

Words this lesson uses

Each one is defined here on this site. Open the entry for the full definition and the other words it points at.

← Versioning inside one repository
Previous Lesson
Versioning inside one repository
Next Lesson
A release that exists only to fix
A release that exists only to fix →