User:SwifT/Complete Handbook/Staying up to date

Versioning

The role of freedom

When you are allowed to do anything you want, whenever you want and wherever you want, you will probably think total chaos is but a few inches away. Yet with free software we see that people work together closely, forming hierarchies built upon knowledge and expertise instead of popularity: most projects are governed as a meritocracy instead of a democracy.

In a meritocracy, the power goes to the people who have shown that they are superior in their field above most others. The hierarchies formed within a larger software project are chosen based on the abilities of the developers and not their charisma or any political decision.

In such projects, the lead developers decide when software is ready. There are generally five states where we can pin software on: in-development, tagged, development release, stable release and revised. We explain those states in the next few sections.

State: in-development

Software that is in-development is software where the developers work on constantly. When you have software installed on your system that is in-development, your software will already be outdated by the time you use it (unless the project isn't quite active of course).

Such software has the latest version of everything: every feature, every bug and every file that has been started is available in the software. Of course, this does mean that there is hardly any quality assurance on the software apart from the quality measures taken by the developers themselves.

Think as if you bought a painting where the painter was still busy painting: you will probably see it isn't finished yet.

If you are interested in such software, you might very well be a good candidate to become a developer for that software. In-development software is often referred to as the software available through the versioning system, such as CVS, SVN or Git. Some distributions allow you to install such software despite it being unfinished. For instance, within Gentoo you can install youtube-viewer version 9999, the in-development version of a command-line utility to launch YouTube videos using Mplayer.

In this case, you will install the software that was in-development at the moment of installing. Every time you reinstall it, the latest in-development program code is used.

Most users however are not interested in the in-development version of any software. Distributions that allow installing such software therefore also protect their users by making sure the user knows what he is doing before he can install such software. In case of Gentoo, you must configure Portage to allow the installation of untested software.

State: tagged and static

When the developers know that the in-development software code works, or they want it as a reference for future development, they tag the software. Such tagged software is often called a snapshot of the in-development code and is given a specific name (most likely the date when the snapshot was taken).

This occurs often when the project does not allow outsiders to use the in-development code straight from the versioning system (for instance because the versioning system is not powerful enough to handle user requests or because they want a subproject to control the quality of the code before it is handed to contributors and interested parties).

Using such snapshots is often preferred to the in-development code because the distributions who use the software can ask the user who uses the snapshot which snapshot they took. Then the developers can install that specific snapshot themselves and see if they can reproduce the problem. When using in-development code, the developer would need to know exactly when the user has installed the in-development code.

Take Gentoo as an example: various (untested) packages are snapshots. gentoo-syntax-20120109 is the snapshot taken on January 9th, 2012 of the gentoo-syntax package which provides syntax highlighting and indentation settings for vim (a popular command-line editor) for editing Gentoo related files.

State: development release

When the developers feel that the software is in a quite good shape, they will tag it again but instead of having it as a snapshot, they will make it a development release. In most cases, such a release is more than just a snapshot: it is made simultaneously with documentation updates, project web site updates and after meeting quality assurance. The project advises people who want to contribute to the development of the project to use at least the development release.

Because of this, such releases are given a specific version. Sometimes you can see that it is a development release by the name. For instance, tor-0.2.3.15_alpha is a development release (because it contains the atom alpha) of tor, an anonymizing overlay network application.

There are three atoms generally used to denote development releases: alpha (quite new, far from ready for production use), beta (should give a nice idea how the program will look and behave like when it is officially released to the public) and rc (release candidate - already contains all the features the final release will have, only bug fixes are accepted).

Previously, lots of projects made development releases. However, lately most projects have stepped down and only make official releases and in-development code. Distributions are now taking on the job of making snapshots and (although to a lesser extent) development releases. Only when major releases are made projects make development releases to make sure the final release is really bug free.

State: stable release

The real release is the stable release. Such releases are generally governed by a specific sub-project of the software project and are made simultaneously with documentation updates, web site updates, and public release information.

If you are not interested in contributing to the project, you should use the stable releases of a project since these releases are very stable (they have undergone a lot of testing), have the most support (user and development community), documentation, etc.

For instance, kde-meta-4.8.3 is an official release of the KDE project (version 4.8.3). You will find that the KDE project itself has written a Press Release: this is an official statement by the project meant for various news sites, editors, distributions and interested users to inform them a new release is made. It contains pointers about the new features and enhancements that are put in the software and where you can download the software release.

The given example, kde-meta-4.8.3, is a great example for us to inform you about versioning numbers. The 4 is the major version. This number only changes when very big changes have happened since the previous release. The 8 is a minor version, informing people that the release has big updates but that they don't warrant a major version bump (a bump means to increase a number by one). The 3 is a release revision (although many people will also say it is a minor version). New releases that only differ in the revision number have small changes that improve stability, resolve security issues and bug fixes, but have relatively minor feature enhancements.

State: revised

While the official project makes stable releases, it is the distribution that makes sure that regular users can install the software on their system. Of course, you can install the software straight from the official project, but then you don't have the advantages that the distribution offers you with respect to software management.

The distribution takes the official release and makes some minor changes to it so that it installs flawlessly on your system. It might add in some eye-candy, add in some additional features that are highly asked upon by the community or change the location or names of some files to make the installation easier to manage.

Sometimes, the distribution finds a bug in the software (based on feedback it has received by users of the distribution or by the developers themselves). Quite often, the distribution will fix the issue for the users of the distribution and release it: in such cases, a revision update is made.

Take gdm-2.20.11-r1 as an example. The official release is 2.20.11 (if you think this is a dull version, check out binutils-2.22.52.0.3) but Gentoo has made one revision release since: this revision improved the user management within the package, corrected the dependencies and introduced a fix for restart problems under heavy load.

Forks

Same software, different software

We have touched the idea of a fork previously. A fork happens when one group of developers is not satisfied with another group of developers and start developing the same software, but differently. This occurs on occasion in the free software world.

For instance, one group of developers might not easily accept new features while there is a huge demand for it. This has happened with blackbox: its developers did not accept certain feature enhancements so a group of developers forked the code. They started fluxbox which was essentially the same as blackbox but its development was different as were the end goals. As of today, both projects still exist.

The role of distributions

Ease of use

Whereas regular software releases can still be quite difficult a distribution makes it very easy to install software. When you want to install software as released by the projects, you still need to know how to install it and what options you need to enable. You need to know what you should have installed prior to installing the software (the dependencies).

When you install software using the distribution, the distribution does all this for you. It will automatically resolve dependencies and conflicts, use the correct installation options and merge the software on your system, registering every file it installs so that uninstallations are easy as cake.

Protecting users from themselves

Because projects have development releases and even snapshots and in-development code, distributions help their users by making sure novice users can not shoot themselves in the foot by installing such software while retaining the possibility of using such releases by more advanced users.

Distributions also register every file installation. If a user wants to install software that overwrites a file, the distribution will make sure this cannot happen or that the changes are reversible. A distribution will also make sure that two packages that interfere can not be both installed on the system.

Feedback to upstream

One of the most important roles of distributions is to provide feedback to the original software projects about how their software functions within the totality of a Linux system. The distributions inform the software projects about bugs that users reported to the distribution and they provide valuable enhancement requests with contributions based on the revision updates they have made themselves.

Quite often distributions have developers working for them who also work on the software projects. It goes without saying that this only improves the cooperation between the two projects.

Taking care of updates

A distribution also takes care of informing the user about updates. Updates can happen for various reasons. The most important ones are security updates. In this case, the distribution warns the user that he needs to update (or accept the pending updates) because there are security issues with his current system.

Other updates are mostly new versions (new features, lots of bug fixes) made by the software project itself (in other words, new releases) or distribution-specific updates (new revision releases by the distribution).