Stability levels
Everything Exalynt builds is at one of four stability levels: Prototype, Alpha, Beta, or GA. The level tells everyone how stable the work is right now, so you know what you can rely on before you rely on it.
- Prototype
Exploratory
Explores an idea so we can choose a direction. Expect it to change completely, or be thrown away.
- Using it
- React to it and help choose the direction. Don't use it for real work.
- Building on it
- Don't build on it. Expect it to be rewritten.
- Alpha
Unstable
Works, but is still taking shape. Expect frequent breaking changes and bugs.
- Using it
- Try it with real work and share feedback. Keep your current way of working as a fallback.
- Building on it
- Build on it only to experiment. Expect its interfaces to change.
- Beta
Mostly stable
Settled enough for real use. Breaking changes and bugs are occasional, and changes are announced ahead of time.
- Using it
- Use it for real work, with a fallback for anything critical.
- Building on it
- Build on it, and watch for announced changes.
- GAGenerally available
Stable
Generally available and stable. It keeps working as it does today; breaking changes only come in a new version.
- Using it
- Depend on it, including for business-critical work.
- Building on it
- Build on it freely. Its interfaces are stable and versioned.
Stability levels exist to help us move fast, not to slow us down. They let us show you early, rough work without anyone mistaking it for something finished, and move it up as soon as it's ready.
Why we use stability levels
Every iteration ends with something real, but real doesn't always mean stable. Sometimes the most valuable thing to build is a quick prototype that settles a direction. Sometimes it's hardening a feature people already use. Both are good outcomes, and they deserve very different expectations.
Without a shared label, those expectations get set by accident:
- A polished prototype gets mistaken for a product, and someone plans around it.
- A business process gets built on an alpha feature, and the next change interrupts it.
- Engineers slow down early work because they're afraid it will be treated as finished, or ship work people depend on without the care it needs.
Stability levels make the expectation explicit, and the same for everyone:
- We can show you work early. A prototype on day two of an iteration is useful feedback, not a risk, because everyone knows what it is.
- You know what you can rely on, and can put early work in front of users without over-promising.
- Engineers know how much to invest. Prototype work can take deliberate shortcuts. GA work can't.
- A wrong direction shows up in days, which is why iterations are short (Sharing risk).
A stability level describes how stable the work is, not how good it is. A prototype that answers its question quickly is excellent work.
Changes and bugs at each level
The cards above cover what the people using something and the engineers building on it can expect. Underneath that is how much each level changes, and how many bugs to expect:
| Prototype | Alpha | Beta | GA | |
|---|---|---|---|---|
| Changes | Anything can change, or it may be thrown away. | Frequent breaking changes, sometimes without notice. | Occasional breaking changes, announced ahead of time. | No breaking changes to this version. They come in a new version. |
| Bugs | Only what's being shown is expected to work. | Expected, even in the main workflow. | Occasional, mostly at the edges, and fixed as they're found. | Rare, and fixed first. |
Moving between levels
There's no review board or sign-off process. When a feature is ready for the next level, the engineer moves it up and tells the client. When a move changes what the client or their users will rely on, such as putting it in front of real users or calling it GA, the engineer checks with the client first. That's usually a quick conversation, not a meeting.
A feature can move through every level in a single iteration, or stay at one level for several iterations. Both are normal. For example, in one iteration:
- Prototype An engineer sketched a new report as a prototype and showed it to the client. The client liked the direction.
- Alpha The engineer built it out so it actually worked, and moved it to Alpha: usable, but still changing.
- Beta With time left in the block, the engineer settled its design and fixed the rough edges, moved it to Beta, and asked the client whether some of their users could try it. The client said yes.
- GA The trial went well, so the report moved to GA.
A larger feature, such as an integration with a system that has many edge cases, might instead stay in Beta for a few iterations while real use shakes them out.
Roughly, a feature is ready to move up when:
| Move | Ready when |
|---|---|
| Prototype → Alpha | The client likes the direction, and it's built to actually work, not just to show the idea. |
| Alpha → Beta | Its shape has settled, so big changes are unlikely, and the main workflows work end to end. |
| Beta → GA | It has held up in real use, and it's ready to be depended on without surprises. |
Engineers use a checklist for each level as a guide to what's typically expected, not as a gate.
- A prototype doesn't have to move on. Many are done once they've answered their question. "Don't build it" is a successful outcome.
- Changes to something already GA usually target GA directly. A new option on a stable feature doesn't start over at Prototype.
- GA doesn't move back down. If a GA feature needs to change in a way that breaks it, the change becomes a new version with its own level, and the current version stays GA.
Breaking changes after GA
A breaking change makes something that worked stop working unless you change something on your side, such as removing a field from an API, changing what a report contains, reworking a workflow people have learned, or migrating data so older integrations can't read it.
Before GA, breaking changes are part of the deal: that's how early work gets better quickly. Once something is GA, breaking changes are made only through versioning:
- The change ships as a new version alongside the current one: a new API version, a new major version of a library, or a new workflow next to the old one.
- The new version has its own stability level. Version 2 can be in Beta while version 1 stays GA.
- The current version keeps working until it's retired, after notice, a migration path, and a deprecation period agreed with the client.
Changes that don't break anything, such as new features, new optional fields, and bug fixes, ship without a new version.
Where you'll see stability levels
- When we show you work, at checkpoints, in release notes, and whenever something moves up a level.
- In the software itself, as a badge next to any feature that isn't GA yet. GA is the default, so GA features usually carry no badge.
- On issues and pull requests, as a label. Marking stability levels explains how engineers apply them.
Frequently asked questions
Does a lower stability level mean lower-quality work?
No. The level describes how stable something is, not how carefully it was built. A prototype is supposed to be quick and may be thrown away; building it to GA standards would waste your capacity. Security and the privacy of your data are held to the same standard at every level.
Do stability levels slow the work down?
No, they speed it up. Because everyone knows what a prototype or an alpha is, we can show you work early and often without it being mistaken for something finished. Moving up a level is informal, and a feature can go from Prototype to GA within one iteration.
Who decides when something moves up a level?
Usually the engineer, who tells you when it happens. When a move changes what you or your users rely on, such as trying it with real users or calling it GA, the engineer checks with you first. For Exalynt's own projects, the Sponsor is the one to check with.
Can I use an alpha or beta feature in my business?
Yes, with the expectations at the top of this page. Beta suits real use as long as you have a fallback for anything critical. Alpha is for trying real workflows and giving feedback. If you start depending on something, tell us, so we can get it to GA.
Does getting a feature to GA cost more than getting it to Alpha?
It takes more work: tests, monitoring, documentation, and hardening the edge cases. Sometimes that fits in the same block, and sometimes it's worth a block of its own. We'll tell you which, and whether it's worth doing yet.
Will a GA feature ever break without warning?
Not on purpose. A bug can still break it, and bugs in GA features are fixed first. Intentional breaking changes go through a new version, and the current version keeps working until it's retired with notice. See Breaking changes after GA.
Why these names?
Prototype, alpha, beta, and general availability (GA) are common software industry terms, so your team and other vendors will recognize them. This page gives each one a specific meaning at Exalynt.