A patch release (often colloquially also known as a point release, dot release, or bugfix release) is a software release of a product or other project, especially one intended to fix bugs or do small cleanups rather than add significant features. Often, there are too many bugs to be fixed in a single major or minor release, creating a need for a point release.
Definition edit
The term "point release" refers to a common method of software versioning in which a major version is followed by a decimal point and a minor version. When a new minor version is released, the number after the decimal point is incremented, e.g. from 7.0 to 7.1, or from 2.4.9 to 2.4.10.[1] The incrementing of the number after the "point" led to this phenomenon being called a "point release".
Scope edit
In a point release, the changes to the software project are typically minor. Such releases are usually reserved for bug fixes, optimizations, security patches, and minor new features. Typically, bugs that affect the broad user population are picked for a point release.[2] Depending on the organization, the size and breadth of a point release can range anywhere from a fix targeted release for a single customer to a general maintenance release or even a service pack. Point releases typically try to be interface-compatible with the previous major release of the software. Also, a point release tends to be compatible with all other point releases under the current minor or major version.[3]
Frequency edit
Point releases are often made available fairly frequently, unlike major releases, which may occur once every few months or years.[1] Point releases can be planned to go out a certain time after a major release or can be released as needed.[4][5] The frequency of deploying point releases varies greatly, depending on the needs of an organization. However, if a critical issue with the current version of the software has been found, an emergency point release may go out very soon after the issue has been discovered.
Risk edit
All releases inherently concentrate risk, as thousands of code changes can make it into a single release.[6] This runs the risk of introducing new bugs with the point release. Regressions can be somewhat mitigated by regression testing, but regression testing is not enough to ensure a stable, bug free environment. Generally, one of the goals of a point release is to minimize risk by making changes based on balancing the user need for a fix, the size of the fix, and the risk of regressions.[7] The risks involved with many software changes being released at once has led some groups to release software following a rolling release method as opposed to doing point releases.[8]
Availability edit
With retail software, point releases are often, but not necessarily, free updates for users of the latest full version, as opposed to major releases that frequently come at some cost even for previous users.[1] The delivery model of the software also affects who may be able to use it. If an organization follows a software as a service model or the software is hosted in the cloud, then a point release may be immediately available to users, with no effort required on the users' part to obtain it. If the software must be downloaded, the user may be required to install the point release on his or her own.
See also edit
Notes edit
- ^ a b c "What is point release?". Retrieved 28 October 2014.
- ^ "Adobe - Support : Release Terminology Guidelines". Retrieved 28 October 2014.
- ^ Team, Commons Documentation. "Apache Commons – Versioning Guidelines". Retrieved 28 October 2014.
- ^ "What is point release? - Definition from WhatIs.com". Retrieved 28 October 2014.
- ^ https://wiki.documentfoundation.org/ReleasePlan (accessed 28 October 2014)
- ^ quality (11 November 2011). "Cloud Difference #3: Point releases concentrate risk unnecessarily (Flemming T Christensen on Quality Collaboration)".
- ^ "StableReleaseUpdates - Ubuntu Wiki".
- ^ Humble, Jez (February 16, 2012). Four Principles of Low-Risk Software Releases – via informIT database.