Release

When software shipped on discs and installers, sending it out was an event that happened once or twice a year. There was no taking it back, so teams collected six months of work and pushed it all at once, and development, testing and advertising all lined up against that one date. Nobody needed a separate word for the act of sending it out. That date was the day the product entered the world.

The web and subscription products changed the arithmetic. When a user refreshes a browser and sees a different screen than yesterday, a team can push ten times a day if it wants to. But the moment pushing became cheap, a new problem appeared: nobody could say what had gone out, or when.

Pagedeck kept running into the same scene. A support ticket arrives asking where the share button went, and Sofia, who has to answer it, doesn't know the button moved. She asks engineering and hears that it shipped last Tuesday. From the sending side it went out; from the receiving side nobody was told. Putting code on a server and putting a change in front of people had been collapsed into one act, so the second half belonged to no one.

A release is the name given to that second half once it was pulled apart from the first. Code landing on a server is a deployment. The moment that code actually reaches users and shows up as a new feature is a release. Splitting the two opened a gap in the middle where decisions and preparation could live: choosing what goes out this time, choosing who gets it first, and making sure the change is announced somewhere.

Naming it also created a unit to count. A team used to talk about "the June version," half a year of changes fused into one lump. Now Thursday's release and the one two weeks later are separate things you can point at. When something breaks, you can say which release it started with, and if you roll back, you can decide how far back to go. Smaller batches follow from the same arithmetic. Ship six months of work at once and finding the culprit takes days; ship twenty changes worth two days of work and there are only twenty suspects. The conclusion that shipping small and often is the safer option comes out of that count.

Inside the product axis, the launch group covers everything about putting finished work in front of people. A single act of sending it out is a release. Opening to one percent first and widening only if nothing breaks is progressive delivery. The plan for who hears about it, through which channel, and how it gets sold is go-to-market. At the far end sits sunset, where a feature nobody uses stops being offered. A release is the point in the middle where the door actually opens.

Seven terms sit under release, in two groups. The groups answer different questions. One asks who can use this right now; the other asks how it gets sent out.

The stage group names how wide the door is open. Five terms line up from narrowest to widest.

1. Alpha — an early build used inside the company or by a handful of people. Half the features are missing and losing the data is an accepted risk. At Pagedeck this is the state where only engineering and Mia are using it.
2. Closed beta — a trial open only to invited users. Because you choose the audience, you control what kind of feedback comes back, and a problem affects a few dozen people rather than everyone.
3. Early access program (EAP) — a program that opens the feature to selected customers before the official launch. The audience is about the size of a closed beta but the character is different: these are paying customers brought in under an agreement to give feedback in return for going first.
4. Open beta — anyone can join, but the product says plainly that it isn't finished. The beta label is an advance apology for whatever goes wrong.
5. General availability (GA) — the state where every customer gets the feature officially. From here support, refunds and incident response apply at the same level as any other feature. Removing the label creates a promise, which is why teams hesitate longest at this step.

Not every feature walks through all five. A small change skips from alpha straight to general availability, while anything touching payments or permissions may sit in closed beta for two months. What decides how long to stay in a stage isn't how polished the work is but how much damage it does if the idea turns out to be wrong.

The stage label is also a signal to users. Shown the same screen, a user who sees "beta" forgives a bug once, and a user who sees a finished product asks for a refund over the same bug. So the decision to drop the label rests on whether the team can carry that promise, not on whether development is done.

The method group names the way something goes out. The two terms in it apply in opposite situations.

• Soft launch — opening quietly with no promotion attached. It suits work that is finished but whose reception you want to see first. Nothing is announced, the feature simply appears on screen, and after watching how people use it for a couple of weeks the team decides whether to talk about it.
• Hotfix — sending out one urgent fix immediately, without waiting for the regular cycle and with the process trimmed to a minimum. It's reserved for situations where every hour costs something, like checkout being broken. The trimming is the point and also the risk: the same steps that slow a normal release down are the ones that catch mistakes, so a hotfix carries only the change that fixes the problem and nothing that happened to be sitting next to it.

A single release usually runs in the order below. The skeleton stays the same whichever stage it opens into.

1. Scope — close the list of what goes out this time. Mia owns this, usually a week before the release date. Leave it open and items keep arriving until the last day, which means the thing being tested keeps changing.
2. Code freeze — the point where nothing beyond the agreed list gets added. Anything arriving after this moves to the next release.
3. Verification — checking that what was built behaves as intended. Theo's side covers whether the functionality works, and Noa checks whether the screens match the designs.
4. Deployment — putting the code in the production environment. Technically this is the end of the line, but users may still see nothing. A feature flag, a switch that turns a feature on and off while the code sits there deployed, lets the team decide when to ship and when to open as two separate calls.
5. Watching — following errors and usage numbers for anything from thirty minutes to a few hours after opening. If something looks wrong, undo it. Returning to the previous version is called a rollback, and a release with no rollback path decided in advance leaves the team with nothing to do at this step.
6. Announcing — telling people what changed. Users hear about it through release notes, and Sofia and Ravi, who talk to customers directly, hear about it earlier than that.

Walking through this by hand every time means more accidents the more often you ship. Steps 2 through 4 are usually automated, and that job belongs to continuous integration and continuous delivery (CI/CD), the setup that verifies code changes automatically and carries them through to deployment. Automation doesn't remove steps 1 and 6. No machine decides what goes out or who needs to hear about it.

"Can that make this release? If not it moves out two weeks."

The scope for this cycle is about to close, so decide now.

"The code went out yesterday but it isn't released. It's still behind a flag."

Deployed, but not yet visible to users.

"This can't wait for the next cycle. Let's send it as a hotfix."

A proposal to skip the normal process and ship today.

Pagedeck releases every other Thursday. On the Thursday before, Mia closes the list of items for the cycle and turns that same list into a draft of the release notes, which goes to Sofia and Ravi first. Sofia marks the items her enterprise accounts are likely to ask about, and Ravi looks for anything worth talking about outside the company. Theo deploys on Thursday morning, Mia watches the error numbers through the afternoon, and if nothing looks wrong the release notes go public.

The order broke once last quarter. A checkout bug went out as a hotfix and the announcing step got skipped, and by that afternoon Sofia had three tickets asking why the checkout screen had changed. The fix was correct and shipping it fast was correct. The problem was that engineering were the only people who knew it had happened. Pagedeck now attaches a one-line internal note even to hotfixes.

The most common mistake is treating release and deployment as the same word. Plenty of teams do use them interchangeably, so it's an easy habit to pick up. But the two have different subjects. A deployment is code arriving on a server; a release is that change opening to users. With a feature flag, you can deploy on Tuesday and release on Friday without any trouble. Blur the words and the sentence "it's out" means different things to different people. Engineering says it meaning the deploy finished, sales hears permission to tell customers, and somebody ends up demoing a feature that isn't open yet.

The other frequent misreading is seeing a release as the last step after development finishes. Timelines draw it in the rightmost column, so the impression is understandable. In practice, though, the time a release consumes isn't the ten minutes spent pressing deploy — it's the front half, deciding what goes out. The meeting that closes the scope, the judgment about which stage to open into, the writing that explains the change to customers: all of it has to start before the code is done. Treat it as a closing formality and you end up deciding "is this safe to ship?" on Thursday morning, on the spot, and decisions made that way tend to end in a rollback.