Linear Release Planning
A release brings weeks of work to users. Planning the release protects quality and reduces last-minute stress. Linear helps teams organize release tasks with projects, milestones, labels, and saved views.
Release Timeline
Week 1-4 Week 5 Week 6 Release Day After BUILD FEATURE FREEZE STABILIZE LAUNCH REVIEW New features No new work Fix bugs Deploy Check metrics in cycles enters release Run QA Monitor Write retro
Everyday Comparison
Think of a restaurant before a big opening night. The kitchen finalizes the menu a week ahead, staff rehearse service, the owner checks equipment, and the team preps ingredients the day before. Surprises on opening night shrink because each step has a deadline. A software release follows the same logic.
Set Up the Release
Use a Project
Create a project named after the version, such as "Release 3.2". Assign a release manager as the lead and set the launch date as the target date.
Add Milestones
Use milestones to mark the key dates.
| Milestone | Meaning | Sample Date |
|---|---|---|
| Feature freeze | No new features join the release | Oct 10 |
| Code complete | All planned work is merged | Oct 17 |
| QA passed | Testers approve the build | Oct 24 |
| Launch | The release reaches users | Oct 28 |
Label Release Work
Create a label such as Release 3.2 and apply it to every issue that must ship. Add a second label named Release Blocker for problems that stop the launch. Blockers receive Urgent priority.
Build Saved Views
Save two views for the release manager.
- Release Scope: issues with the Release 3.2 label, grouped by status.
- Release Blockers: issues with the Release Blocker label that remain open.
Open these views in every release meeting. The blockers view should shrink toward zero as launch day approaches.
Stabilization Cycle
Dedicate the final cycle to quality. Engineers fix bugs, testers verify fixes, and writers finish documentation. Refuse new feature work during this cycle. Any late request goes to the next release backlog.
Launch Day Checklist
Create a template issue with sub-issues for launch tasks, then copy it for each release.
[ ] Final regression test passed [ ] Release notes published [ ] Support team briefed [ ] Deployment scheduled [ ] Monitoring dashboards open [ ] Rollback plan confirmed
Roles During a Release
| Role | Responsibility |
|---|---|
| Release manager | Owns the timeline and the blockers view |
| Engineering lead | Confirms the build is ready |
| QA lead | Signs off on test results |
| Support lead | Prepares answers for customers |
After the Launch
Watch error rates and user feedback for several days. Create issues for any problems found. Hold a short retrospective and record what worked and what needs change. Store the notes in the project for the next release team.
Plan for Problems
Every release carries some risk. Write a rollback plan before launch day and test it on a staging system. Agree on who decides to roll back and which signals trigger the decision, such as a sudden rise in error rates.
Communicate With the Company
Post release dates and scope in a shared channel. Sales and support teams use the information to prepare customers. Send a final reminder one day before launch with the time, the contact person, and the location of the release notes.
Plan Smaller Releases
Frequent small releases reduce risk. Each release carries less change, so problems are easier to locate and fix. Teams that release weekly often find the process calmer than teams that release quarterly.
Document What You Learn
Write a short note after every release listing surprises, delays, and ideas. Store the note in the release project. The next release manager starts with a head start and avoids repeating old mistakes.