Why I am writing about this
I used to think software versioning, alpha, beta, all of that, sounded very cool but was only meant for software released to outside users and customers.
Because why would internal users care if I told them it was an alpha version? They probably would not even appreciate the jargon.
I was wrong. And I learned it the way I learn most things. On the job.
Release versioning is not there to make you sound like you work in Silicon Valley. It is there to bake quality processes into your software development lifecycle.
And that, in the end, improves the quality of the product your users get in their hands.
We know internal users love quality software. And the moment it does not work, they hate it, because it stops them from doing their job.
Which is the whole reason release stages exist: to catch the broken thing before your users do.
And the way we handle release versions for internal products differs a little from B2C and B2B. Just because of the internal nature of things.
Why should you care?
Here is my honest answer. Every single benefit fits under one word. Quality.
But let me break it down.
- Clear process. Ever felt uncertain about what testing you did, what you skipped, and at what point each check should happen? Versioning gives you that structure.
- Happy users. Ever had users complain about bugs you could have caught earlier? Stages catch them before your users do.
- Shared language. When everyone agrees what “beta” means on your team, you stop arguing about whether something is really done.
- Fewer surprises. You know what is ready for production and what still needs work, long before it reaches anyone.
Let us settle the battle once and for all (deployment vs. release)
Before we get into release lifecycle versioning, we need to clear up one thing.
It is the thing almost everyone in the internal product world confuses. The thing you read, try to memorize, and then forget the next time you need it.
Deployment vs. release.
Today we are talking about the release lifecycle. Making the software available to your users.
It often gets mixed up with deployment, which is pushing the code to production.
So the order goes like this. First you deploy code to the environment. At that point, you decide whether you actually release it to users or not.
Of course, that only works if you have a release mechanism in place, like feature flags, that let you keep features turned off for users until you are ready.
Here is how I think about it.
Deployment is the staff stocking the shelves and setting up the store before opening. The products are all there, but the doors are still locked.
Release is flipping the sign to “Open” and letting customers walk in.
Your code can be sitting in production, fully stocked. Until you unlock the door with a release, nobody gets to use it.
The stages of the software release lifecycle
There are five.
- Pre-alpha. The product is still being built. Development is in progress.
- Alpha. Development is finished, and the software goes through structured testing.
- Beta. A selected group of real users gets their hands on it and gives feedback.
- Release candidate. The version that is ready to ship, once the last bugs are sorted.
- General availability. The production version. It is live and available to everyone.
How do you do release versions for internal products?
For internal products and software, the stages stay the same. What changes is what you do in each stage, and who you release it to.
Pre-alpha
- What you do: The product team is building the software.
- What you check: Developers run unit tests. A tester does a functional check, or I do it myself as the PM.
- Who gets it: No one outside the product team.
- My take: We do our best here, but we are not enough on our own. A lot of teams stop at this point. I hope you do not.
Alpha
- What you do: Development for the planned scope is finished.
- What you check: Structured testing against test plans, manual or automated. Functional and non-functional.
- Who gets it: Still no real users. Internal only.
- My take: This is your last quiet window to break things before someone who depends on the product does. Use it.
Beta
- What you do: Release the working version to a selected group.
- What you check: UAT and real user feedback. Speed matters here, get to it fast.
- Who gets it: Power users, or the lucky few who get to try it first.
- My take: My one trick: release in parallel while alpha is still running, so feedback arrives before you have fixed every bug. Just never expose anything critical that is still misbehaving.
Release candidate
- What you do: Fix the last bugs you care about, and decide which ones can wait for the next release.
- What you check: A final go or no-go review of what is left. You are triaging, not building.
- Who gets it: No one new yet. This version is ready to deploy.
- My take: The real skill is not fixing everything. You never will. It is the discipline to decide what is good enough to ship now and what has to wait.
General availability
- What you do: Deploy to production and make it available.
- What you check: Continuous monitoring, then maintenance and improvement.
- Who gets it: Everyone.
- My take: This is the part people get wrong. GA is not a finish line, it is the start of the next loop. And once you have done it once, it gets easier the next time.
Download: the checklist for passing each release stage
I put together a checklist of what to tick off before you move from one stage to the next. Save it, and run your next release against it.
CLICK HERE TO DOWNLOAD
