What Is a Software Release? The Ultimate Guide

A software release is a specific, well-defined event in the life of a software product. Understanding it properly impacts how you plan and test changes before communicating them to the people who use your software.

This guide starts with a quick software release definition, before walking through the main types of releases you'll encounter, the stages a release moves through before it's final, and how continuous integration and feature flags have changed what a release even looks like day to day.

What is a software release?

A software release is a set of code changes—new features, fixes, improvements, or some combination of the three—that's packaged up and made available to users as a specific, identifiable version of a software product. It's the moment a change stops being something the development team is working on and starts being something users can actually access.

That's a narrower definition than it might first seem. Writing code isn't a release. Testing code isn't a release. Even pushing code to a server isn't necessarily a release, if nobody can see or use the result yet. A release is specifically about availability: has this change been made available to the people it's meant for?

The definition of a software release has changed over time, particularly with the development of SaaS.

In the past, when software shipped on physical media or as an occasional download, "release" and "deployment" were close enough to the same thing that nobody needed to separate them. Today, with software running continuously in the cloud, a team can push code to their production environment and still control exactly when, and to whom, it becomes visible.

Types of software releases

Not every release carries the same weight. A new release might be a complete product overhaul, or it might be a one-line fix nobody notices unless they were affected by the bug it solves.

Software teams generally group releases into three categories, based on their scope and impact on end users.

Major releases

Major releases introduce significant new features or a substantial redesign—sometimes a meaningful shift in how the software product works, sometimes a visual overhaul on top.

They're usually planned well in advance and involve careful orchestration across multiple teams, often with their own communication plan so users aren't caught off guard by the change: release notes, in-app messaging, a dedicated announcement, or some mix of all three.

Because major releases affect a large surface area, they carry the highest risk and require extensive testing well before the production release date, not just a final check right before launch. If the release changes core workflows, it's also worth budgeting time for user training, so people aren't left guessing at key features on launch day.

Minor releases

Minor releases sit a step down in scope. They usually bring smaller feature additions or usability improvements that build on what's already there rather than reinventing it—a performance enhancement here, a workflow tweak there.

Minor releases don't typically need the same cross-team coordination as major ones, but they still deserve proper testing, since even a small change can have outsized effects in a production environment.

Patch releases and emergency fixes

Patch releases (sometimes just called bug fixes) address specific, known issues, and they tend to move faster through the software release process than major or minor releases.

Emergency fixes go a step further: they're unplanned releases triggered by something urgent, most often security vulnerabilities or an issue causing real damage in production.

Speed is usually more important than the usual careful planning in these cases, though skipping testing entirely on an emergency fix risks creating a second emergency shortly after the first.

The software release lifecycle

Before any change reaches end users, it typically passes through a series of stages that make up the software release lifecycle. Not every organisation follows every stage formally, but most software projects recognise something close to this progression.

• Pre-alpha: Everything that happens before testing starts, including gathering requirements and scoping the work, and then writing the initial code. Nothing in this stage is stable enough to test properly yet.
• Alpha testing: The development team starts validating the software's behaviour internally, often before anyone outside the company sees it. Bugs found here tend to be the most fundamental, since alpha builds are the least polished.
• Beta testing: The software opens up more widely, either to a group of real users who've opted in or to a broader internal audience. During this beta stage, the team gathers user feedback under closer-to-real conditions than alpha testing allows, catching usability issues and edge cases that internal testing missed.

Beta testing typically includes a few stages, which some teams consider as separate, such as some amount of user acceptance testing (UAT) to confirm the software actually meets what users need, not just what the spec described.

What is a release candidate in software?

A release candidate is a version of the software that's passed through alpha and beta testing and has had its known bugs addressed. It's now considered a strong contender to become the final release, provided nothing significant turns up during this last round of evaluation.

It's not a guarantee: if a release candidate reveals a serious bug, the team fixes it and cuts another release candidate rather than shipping the flawed version.

Once a release candidate clears system testing and integration testing without any major issues, it's promoted to the final version—also called the stable release, or general availability (GA)—the point where that specific version is considered ready for general use and meets user expectations well enough to stick around until the next release.

Software release vs. software deployment

It's easy to use "release" and "deployment" interchangeably, and in plenty of organisations, they still happen at the same time.

However, they describe two different things: deployment is the act of pushing code to a production environment, usually owned by operations teams, while release is when that change becomes available to users. They don't have to happen together.

This separation is what reduces the risk in modern software delivery. Feature flags enable a development team to deploy code to production while keeping a new feature switched off, invisible to users, until it's ready to go live. Flipping the flag on is the release; the deployment already happened, quietly, potentially days earlier.

Teams can decouple risky deployments from user-facing releases, testing a change against real production traffic without any end users noticing if something's off.

If an issue does surface, turning a flag off is a lot faster—and a lot less stressful—than rolling back an entire deployment. It's a meaningful way to reduce risk for software developers and operations teams alike.

Reducing risk in your software release process

Every release carries some inherent risk, sometimes because it involves people, and human error is a constant even in a well-run development phase, but also because many releases now involve AI-generated code.

A solid release process is unlikely to eliminate risk entirely. However, it will help you to catch problems before users do, and to limit the damage when something slips through anyway—which is what separates a successful software release from a stressful one.

Testing does most of the heavy lifting here, across a few distinct layers:

• Unit testing checks that individual pieces of code do what they're supposed to, in isolation.
• Integration testing confirms those pieces work correctly together, not just on their own.
• System testing validates that the whole application behaves as expected end to end.
• User acceptance testing brings in actual users or their close proxies to confirm the software meets real-world expectations, not just the technical spec.

According to the 2024 Accelerate State of DevOps Report, elite-performing engineering teams have a change failure rate up to eight times lower than low performers—a gap that comes down to disciplined testing and planning, not luck.

When compared to low performers, elite performers have:

Beyond testing, observing a few key practices consistently separates a successful release from a rocky one:

• A clear rollback plan for when something goes wrong.
• Active monitoring of the production environment immediately after release.
• Communication channels that keep users aware and internal teams aligned on what's changing and when.
• Staged exposure, so a new release reaches a small percentage of users before everyone else.

Feature flags cover that last point directly, letting a team roll a release out through progressively wider rings of users rather than exposing everyone to a change at once.

That said, feature flags reduce the blast radius of a bad release, but they don't replace the testing and planning that should happen before a release goes out in the first place.

Release management: process, roles, and tools

Software release management is the discipline of planning and coordinating the software release process, overseeing everything from the moment a change is ready for release through to its arrival in production and beyond.

On larger software projects, this often falls to a dedicated release manager, whose job is to keep the release process moving and flag risks before they escalate.

They act as the point of contact across engineering, quality assurance, operations, and support teams, and they need to communicate effectively with all of them to keep a software project on schedule.

Effective release management usually includes a few consistent pieces:

• Release planning to schedule what's going out and when.
• Release notes so users and internal teams understand what's changed.
• Communication channels for flagging issues if the release doesn't go as expected.

Release management tools help with the operational side of this, tracking what's in a given release and automating parts of the release management processes, while giving support teams visibility into what changed if a user reports a problem.

None of this replaces good judgement, but it does keep customer satisfaction high across a string of new software releases, as a software product and its user base grow.

How CI/CD has changed the software release cycle

For a long time, the standard software release cycle meant infrequent, large releases—months of work bundled into a single, high-stakes production release.

Continuous integration and continuous delivery (CI/CD) changed that model considerably, shortening the development cycle within the wider software development lifecycle. Instead of batching changes, software developers merge and test code continuously, often multiple times a day, catching integration problems while they're still small and cheap to fix.

As mentioned, the same DORA research cited earlier found that elite teams complete 182 times more deployments a year than low performers, shipping on demand rather than in occasional, high-stakes batches.

This shift doesn't just make releases faster; it makes them safer.

Smaller, more frequent releases are easier to test thoroughly and easier to roll back if something's wrong—and when a bug does appear, it's easier to trace back to the specific change that caused it.

Combined with progressive release strategies, CI/CD lets teams treat the software release cycle as an ongoing, low-drama process instead of a periodic crisis, supporting the kind of continuous improvement that's hard to achieve when every product release is a major event.

It also leaves more room for ongoing maintenance and for feeding user feedback and market demands into future releases, rather than locking a roadmap in place for months at a time.

Conclusion

A software release is ultimately about control: control over when a change reaches users, and control over how much risk it carries.

It also determines how quickly a team can respond if something goes wrong. Understanding the difference between a release and a deployment, and where a release candidate fits in the lifecycle, gives you a much clearer picture of how modern software actually reaches the people using it.

If you want that kind of control over your own releases, Flagsmith's feature flag management platform lets you decouple deployment from release and roll changes out gradually, with the option to switch a feature off in seconds if it's not working as expected.

Sign up for free and see what a lower-stress release process looks like.

Software release FAQs

What is a release in software development?

In software development, a release is the point at which a specific, tested version of an application is made available to its intended users, whether that's the general public or a smaller, opted-in beta group. It marks the transition from being in development to being in use.

What's the difference between a release and a version?

A version is a label—a specific point in a piece of software's history, usually marked with a version number.

A release is the event of making a particular version available to users. Every release corresponds to a version, but a version can exist internally without ever being released, and a release is just one moment within a much longer product lifecycle.

How often should a team release software?

There's no universal answer, since it depends heavily on the product and how much risk a given release carries.

Teams practising continuous delivery might release multiple times a day, while others, particularly in regulated industries, release far less frequently but invest more heavily in testing and staged rollouts before each one.