In software development, a rolling release approach refers to a continuously evolving software system, as opposed to one with versions that must be reinstalled over the previous versions. It is one of many types of software release life cycles.
A rolling release is typically implemented using small and frequent updates. However, simply having updates does not automatically mean that a piece of software is using a rolling release cycle; to qualify as a rolling release, the philosophy of developers must be to work with one code branch, as opposed to discrete versions.
[edit] Examples
- The Debian Linux distribution has two rolling releases, known as "testing", and "unstable"; one can install the operating system just once and install small upgrades from time to time, and it will always be up to date; but Debian "stable" is not a rolling release.
- Sidux is a rolling release based on Debian's "unstable" rolling release.
- Arch Linux
- Gentoo is a rolling release, the different releases just reflect the state of the distribution at that time.
- Foresight Linux is based on rPath Linux (and its Conary package management).
- The FreeBSD operating system uses a rolling release for packages, and uses -STABLE and -CURRENT branches for development between release snapshots.
- PCLinuxOS
- Zenwalk Linux
Non-examples:
- Windows, Mac OS and most Linux distributions are not rolling releases, because 1) they have significant changes between version numbers (a complete operating system reinstall, or at least a major upgrade, is required), and 2) significant development effort is spent on keeping old versions up to date and propagating bug fixes back to the latest branch, as opposed to focused on the latest development branch.
[edit] Focus of effort
It is common to occasionally take snapshots of the rolling release, which can be refined and "frozen" and only maintained for security. This is often impractical since it requires duplication of effort. Typically, defects and characteristics of a particular release are not specifically addressed in a separate/isolated effort (e.g. as patches); instead, they are addressed in the main development effort.