A software release is a set of changes that updates or adds new functionality to a software product or service. There are a few different types of releases, which we can delineate based on the purpose they serve, their scope, and impact on users. An organization will likely be doing some combination of these releases throughout the year, depending on how they structure their software development lifecycle and software release lifecycle. Let’s explore them:

Three main types of software releases:

Major releases

Purpose

Major releases typically introduce new software or an updated version of the software with new features and functionality, and are often accompanied by a marketing push to make users aware of the new release. Sometimes a major release focuses on the user experience of the software, changing the flow or manner in which a user interacts with the product without necessarily adding new features. A major release might also be an overhaul of the visual design of the product.

Impact

A successful release will usually have a noticeable impact on end-users, for better or worse! The release might bring them long-requested features, or force them to learn a new path to interact with the product. A substantial change such as Instagram switching from its chronological feed to one dictated by an algorithm was a major release, and illustrates how a major release can be a divisive one for users too. Sometimes a major release can also have unexpected effects such as degraded performance or downtime, both of which may be noticed by users.

Who is responsible?

Major releases require substantial cross-functional collaboration, involving stakeholders across an organization from executives, to product management, engineering, marketing, sales, and customer support.

Minor releases

Purpose

Minor releases usually introduce bug fixes or performance enhancements, and are sometimes referred to as patch releases (as in patching over a hole). Minor releases often address usability issues or other problems reported by users resulting from changes introduced in a major release.

Impact

 A minor release may not be discernible to users unless they experienced the bug or performance issue. As with major releases though, unintended consequences of a change might be noticed by users if a service becomes slow or fails. 

Who is responsible?

Issues requiring a patch release are often surfaced through customer support, as users report bugs or other problems resulting from a release. Depending on how an organization is set up, support engineers may create the fix themselves and submit it to the relevant development team to review. In other orgs support may submit a bug report for the engineering department to triage and address.

Emergency releases

Purpose

Emergency releases are unplanned, urgent software updates that address a critical issue. A security vulnerability such as Log4Shell or major performance issue might necessitate an emergency fix that needs to be applied outside of a product’s regular release cycle. You might have heard of these referred to as “hotfixes.”

Impact

The impact to users (if any) is usually felt in the form of downtime if you’re unable to apply the fix without interrupting service.

Who is responsible?

When critical vulnerabilities or performance issues arise, the first team members to respond are usually engineers on call. These might be site reliability engineers or support engineers. Depending on the nature of the emergency, the development or IT operations team responsible for that area of the product or your infrastructure might be called in to make the fix. In some cases, the severity of the issue might require your executive and communications teams to get involved in communicating the issue, impact, and remediation plans to your user base.

The stages of a software release cycle

1. Pre-alpha: This stage encompasses all activities that lead up to a major release, including gathering requirements, deciding on the pricing for new features, design, and development. 
2. Alpha: This is usually where testing and validation of the new code’s behavior begins. Alpha releases are typically tested within the company. 
3. Beta: Once software passes alpha, it enters the beta stage. Some companies share the beta with prospects and customers as a demo, or make it available for beta testing by a group of users who opt in. This can be a good way to engage your power users or people interested in early access to new features. 
4. Release candidate/s: Once any bugs surfaced in beta testing have been addressed, a release candidate is ready to undergo evaluation for stability and suitability as the final version of the software to be released. 
5. Final release: If no significant bugs emerge when testing the release candidate, you’re ready to release the final version. When and how you do that will depend on your methodology and deployment and release strategies (we’ll dig into those below).

How the software release lifecycle has evolved

The nature of software releases has changed as the manner of distribution has changed. 

When new software was released on floppy disks or CDs, it was common for as much as a year or more to pass between releases. The software development lifecycle (SDLC) was largely defined by waterfall methodology: a linear, clearly-defined set of processes, each managed by different groups. The release was the last stage in a long line of activities. 

As internet use grew and software became available to download over it, waterfall began to give way to Agile methodology. With Agile, new software is broken down into smaller iterations and milestones, released more frequently. Agile enabled companies to move faster and gather end-user feedback at regular intervals to integrate into the product. 

DevOps, which builds on Agile, then emerged around 2008 in reaction to the frustrations arising from Agile’s focus on development processes, to the exclusion of operations. The lack of coordination between the two disciplines was frustrating for teams and had a knock-on effect on users: new features were unreliable in production because the developers who wrote the code had no insight into the environment in which it had to run.

DevOps is a set of practices that aim to improve collaboration between development and operations teams. DevOps puts an emphasis on automation to reduce time spent on repetitive tasks and the scope for human error. For example, continuous integration and continuous delivery automate the merging, testing, and deployment of new code into production. These practices are especially impactful when working with software hosted in the cloud (or Software-as-a-Service/SaaS), because users get to access improvements and fixes almost immediately. 

The role of release management

Even as Agile and DevOps moved the industry away from infrequent “big bang” releases, with all of the stress and coordination they entail, the increase in number of releases means that the processes around them have had to evolve as well. 

Release management may mean different things at different companies, with some organizations having a dedicated release manager while others rotate the role depending on which team or department is responsible for the new feature being released. 

Whatever form release management takes, the role of the release manager has shifted from release planning and overseeing the release management process (a project management focus). Release managers now have an opportunity to drive business value by identifying bottlenecks in the release pipeline, observing how customers are interacting with the new release, and translating metrics associated with the release into insights for other departments. In many ways, release managers have had to develop more hard technical skills; instead of creating Gantt charts they now might be poring over continuous integration pipelines.

Release != deployment

Sometimes people talk about software deployment and software releases interchangeably, and in some organizations there may be no distinction between the two. Software deployment refers to when you push changes to your production environment. The software release—which can happen at the same time as deployment or afterwards—is when those changes are made available to users. With the rise of more sophisticated deployment strategies, you can decouple the product release to users from when it’s deployed to your production environment. 

This is usually achieved through advanced deployment strategies, for example:

Canary deployments

Canary deployments involve maintaining two instances of your production environment and deploying the new version of your application to a small subset of your users (your “canary”) first. You can read more about canary deployments and other deployment strategies here.

Feature flags

Feature flags are another way to decouple deployment and release of new features. Feature flags (sometimes called feature toggles) enable you to toggle a feature on or off without deploying new code. Exposing users to the new feature is now controlled by simply flipping a switch. Feature flags unlock progressive rollouts: enabling you to experiment by releasing features to select groups of testers to validate first, or testing an earlier version of a feature discreetly before rolling it out to everyone. Traditionally, testing how a new release performed and was received by users had to happen under a microscope. The whole world was aware of the new release and could see when things went wrong. Now you’re in control of when you announce it.  

“Every developer makes a rollback-worthy mistake every x changes. This means your probability of having a clean release is (1-1/x)^NumDevs (assuming everyone submits 1 change/release).

Let's give it 1/100 bad code change, and 100 devs. The probability of a clean push is:

(1-1/100)^100 = 0.36. That's worse than a coin flip.

for 10 devs = 0.90. Still not great, one push in 10 will be bad.

When you're trying to push daily (or even more frequently), this will kill the team's velocity. It's even worse when there are interleaving changes making rollback and re-release impossible before the next release. Rollback and freeze is a problem when you're trying to meet deadlines (either marketing or regulatory).

Feature flags allow the code to go in and each change to be rolled back independently. This lets the rest of the team make progress while the bug is debugged.”—jpollock on Hacker News

However you achieve it, decoupling deployment from releases alleviates some of the stress traditionally associated with big releases, because you have a chance to conduct software testing in production and monitor the performance of the release before rolling it out to all users. In the event of a bug or performance issue, you can roll back or toggle off the relevant feature flag quickly without your customers even being aware of any changes.