The Importance of Major, Minor, and Patch Releases in The Iterative SDLC
Software development is not a linear process but involves continuous feedback gathering, evaluation and upgradation. Upgradation helps to eliminate bugs, improve efficiency, and add new features to keep up with the market needs. Upgrades can be both reversible and non-reversible and of various scales. Each upgrade will have a version name or number assigned, helping it to be distinctly identified from the rest. Versions can be broadly categorized as major, minor, or patch releases depending on the level of changes it introduces to the software. However, we should make a note here that none of the versioning does change the essential product, but only increases functionality or fixes problems.
The importance of versioning in software
Systematic versioning of a software is very important for users to understand more about the software version they are using. Versioning has serious business implications for software vendors which helps them to segregate them, gather insights, and develop monetization plans.
Whenever a new version is released the questions that can arise to the mind of a user are:
- How old is the current version being used in production from the latest release?
- Are the security patches upgraded?
- Is there a risk of losing data or glitches triggering upon upgrading to the latest version?
- What kind of disruptions may happen to my business as a consequence?
The answers to these questions lie in the version number or name. It is very common for organizations to number their version especially, following the semantic versioning.
Major.Minor.Patch – the semantic versioning
The semantic versioning is a very systematic style of numbering the versions so that a client can easily understand what this version is about and where it stands on the product roadmap. Whether it is a major release and existing version must be adopted to allow things to work perfectly in the near future or whether it is an optional patch which might be skipped. The typical representation of semantic versioning is X.Y.Z (Major.Minor.Patch).
Let us understand what is a major, minor or a patch version from a typical API versioning perspective.
A major version is when you make incompatible API changes. This means a consumer cannot upgrade without changing their software where applicable. Let us consider an API being used by multiple frontend clients. Suppose a API endpoint name is changed then all the frontends accessing this API will be unable to communicate with the API with the old endpoint name still serving as the node. So this kind of situation demands an upgrade to the latest version of the API. Every nth major version is represented by a version number like N.0.0 .
A minor update is when a functionality is added in a backward compatible manner. Typical examples are when a new feature is added. You may choose to update and integrate this new feature to your interface and improve the value of your software. However, not upgrading is not going to break anything as none of the existing functionalities are not removed. Adopting a minor version may help to improve the value proposition of an API before its business users, bringing in additional functionalities. However, we should keep in mind that we cannot jump to a minor upgrade without upgrading the corresponding major for that version.
Say an API releases a version 5.3.0 here, 3 stands for the third minor upgrade and 5 stands for the major version then the user must already be using a version above 5.0.0 to directly upgrade to this latest version or preliminarily upgrade to 5.0.0 from a lower version.
A patch update is interchangeable which the users can freely upgrade to or downgrade from. The last set of digits in the version number represents the patch. Examples of patches are mainly bug fixes, performance improvement, tweaks in environment etc. Patches does not bring in any new feature, only internally tweaks the existing feature to eliminate bugs and enhance performance.
In the previously discussed example let’s say we added some feature in the version 5.3.0 but in Android phones this is not working correctly due to some bug. The development team will add the necessary changes to the codebase and release a patch and version name will be 5.3.1 where 1 stands for the first patch released for this minor version.
Maintaining a Streamlined Release Experience for Your Customers
Maintain clear communication
Clear communication is the key to creating trust. Your releases impact your customers and they should be given a clear idea of how. Information about what this upgrade is about can be shared over mail and clearly recorded in documentation. This keeps the customer aware about what are the new changes and prevents them from suddenly being taken aback when support is discontinued for the currently used version. Changes are documented as release notes. Your users are both technical and non-technical and the release note should be written in clear statements in a transparent and specific manner enough even for non-technical users to understand what to expect from this release.
A good release note clearly answers the following questions:
- What’s new?
- What’s been fixed?
- What’s been improved?
- What’s been deprecated?
It is broken down into smaller sections making it easier to search for specific information. This kind of clarity opens up a different level of communication with the customer. Release updates via periodic mailing and notification helps the customer understand what’s new and how the product is making progress according to a defined roadmap.
Publish your release schedule
The Release schedule should be developed in conjunction with the organization’s portfolio management team to ensure that value is delivered to the customer, based on strategic business priorities and considering the interdependencies between projects and programs. Publishing your release schedule is another way to keep the customers well informed and prepared about upcoming releases. Release schedule can be published in the company website and also by notifications sent through mail or in-app pop ups. Publishing the release schedule helps to build a sense of inclusion and trust among the users. It ensures everyone is aligned with the release schedule, outage requirements, and any freeze periods (e.g., to protect month-end and corporate reporting). They can plan their time and resources ahead of upgrading to a release which in turn helps them in managing their expenditure.
Build and maintain consistency
Building and maintaining consistency is another way to keep your users believing in you. People love predictability and this gets all the more important when it comes to using a third party product to plan their upgrade schedule. If there is a frequency of making a major release that interval should be uniformly maintained by all means. This creates a sense among the users being a part of the product ecosystem and they eagerly await for that event.
The naming convention is also another important factor that maintains consistency. Semantic versioning is an ideal convention for this as by looking at the version number of the release users can exactly identify the position of the release in the product journey and what it brings than it would have been the case if they were versioned by alphabetic name.
Follow a release policy
A release policy is crucial to having a disciplined release schedule and building customer trust. The release policy should be built observing a release strategy and should address:
When to have a major release?
When to have a minor release?
A clear governance structure for release
A release strategy is tailored to organizational needs guided by their best practices. The strategy considers release types, standards, and governance requirements for an organization. All deployment methodologies must be able to abide by this release strategy. A clear governance structure needs to be developed to support the release strategy.
A common release strategy is the release train strategy. This is suitable for large complex changes involving multiple project teams working towards a larger release program. Every release is done following clear milestones. There are trains of weekly, monthly, or quarterly release. Weekly a minor release maybe launched while monthly/quarterly a major release comes up.
Every large project or program comes as a major release. any feature or enhancement that contains a high or critical business impact, even retrofits, should integrate into this release. The governance framework of a major release ensures meticulous risk management, safeguarding the production environment and ensuring uninterrupted business continuity.
Before the start of the deployment activities, a Go-No-Go meeting should be convened to approve a major release deployment to review the following key criteria:
- Solution readiness (system, process, and data including testing)
- People and organization (business and IT readiness)
- Release cutover and Go-Live readiness
- Handover to service management
- Operational risks
- Regulatory and compliance
- A list of conditions that needs to be satisfied (prior to the start of deployment) can be included in a “conditional go” decision to ensure any actions from the Go-No-Go meeting are met before starting the release cutover.
Minor releases are done with an aim to avoid regression risk. They are business as usual (BAU) and routine changes. Impact assessment tools can be used to ensure all objects included in a minor release are not invasive by nature. All new features or enhancements that contain a high or critical business impact should await a major release.
Get user feedback
A major stake in the software development lifecycle comes from feedback gathering. It is important to collect feedback around release practices. What are your users saying about it? Do they like the structure? Is it helping them? Have they complained about it? Are you moving too quickly for them with major releases? Are there too many outdated dependencies getting piled up before the next major release? Your software is there to help your customers and your release policy should make their life easier.
Conclusion
Major, minor, and patch releases breakdown the software upgrade strategy into small iterative intervals making it easier for your customers to consume the changes. A well thought release strategy prevents version promiscuity. It also prevents the software from getting locked in a dependency hell from surmounting technical debt arising from version locking. Releases are the milestones perfectly aligned between the two in today’s iterative SDLC.
