Ceci est une ancienne révision du document !
In the world of software development, a distinction is made between various stages of software during its production process. A piece of code that has just been made up may be referred to as pre-alpha, and should really be considered as no more than work-in-progress. Once the application or library has evolved to the point that an end-user could potentially use it more-or-less as it is supposed to work, then it goes into alpha status. This does not mean it is finished, but needs some level of user interaction with the software and its developers to detect and eliminate bugs. It then goes on to beta status, where more user testing and bug detection goes on. The actual difference between alpha and beta depends a little on how things are organized for that particular project, but, in general terms, alpha is usually tested in-house by members of the business or organization that is producing the application, while beta testing is performed by a larger community. There is also a question of feature freeze, which is the point in time at which no further features will be added to the software before final release – all modifications being limited to just making sure the features already incorporated into the product actually work. Alpha software does not usually have any freezing applied to it, and some features may morph as development goes on. Beta software usually is frozen to some extent, in the sense that major modifications should —in theory— no longer be considered until the time comes for the next release. Finally, a further stage called a Release Candidate may be distributed as a final check before the production-ready version of the software is made public, though not all organizations actually do so.
Dans le monde du développement des logiciels, on distingue diverses étapes du logiciel au cours du processus de sa production. Un élément de code qui vient d’être créé peut être nommé pré-alpha et devrait être vraiment considéré comme un travail en cours et rien d'autre. Une fois que l’application ou la bibliothèque a évolué au point qu’un utilisateur final pourrait éventuellement l’utiliser plus ou moins comme elle est censée fonctionner, elle progresse au stade alpha. Cela ne veut pas dire que c’est achevé, mais que le logiciel a besoin d’un certain niveau d’interaction avec un utilisateur pour que ses développeurs puissent déceler et éliminer des bogues. Ensuite, il atteint le stade bêta, où davantage de tests d’utilisateur et de détection de bogues ont lieu. La vraie différence entre l'alpha et le bêta dépend en partie sur l’organisation des choses pour le projet précis, mais, généralement, un logiciel alpha est testé en interne par des membres de l’entreprise ou de l’organisme qui produit l’application, alors que les tests d’un bêta sont faits par une plus grande communauté. S’ajoute aussi la question du gel des fonctionnalités, ce qui est le stade auquel aucune autre fonctionnalité ne sera ajouté au logiciel avant sa sortie finale ; toutes les modifications sont alors limitées à s’assurer que les fonctionnalités déjà incorporées au produit fonctionnent bel et bien. Habituellement aucun gel n’est appliqué aux logiciels en stade alpha et certaines fonctionnalités peuvent changer au fur et à mesure que le développement avance. En général, les logiciels en stade bêta sont gelés jusqu’à un certain point, dans le sens où des modifications importantes devraient théoriquement ne pas être envisagées jusqu’au moment de la préparation d’une nouvelle version. Enfin, une étape appelée Release Candidate (RC ou pré-publication) peut être distribuée comme dernière vérification avant que la version du logiciel soit rendue publique, bien que tous le organisations ne le fassent en fait pas.
How does this work for Ubuntu distributions? In actual fact, each team (Ubuntu, Xubuntu, Ubuntu Budgie…) has different philosophies and ways of implementing the software release model described above. To complicate facts further, specifics have also been known to change between versions. To take an example, at the time of writing, both Ubuntu 20.04 and Ubuntu 20.10 have been made public as production-ready distributions, the first as a long-term-support (LTS) version to be supported for five years or more, and the second as a standard version with support of nine months or until July of 2021.
While these are being used in production by users, the next version of Ubuntu —called Hirsute Hippo, or Ubuntu 21.04— is being prepared. Slated for final release at the end of April of 2021, a beta version should appear on or about April 1st 2021. Features will have been frozen a week earlier. The complete release schedule can be seen through the following link: https://discourse.ubuntu.com/t/hirsute-hippo-release-schedule/18539
So, what about earlier development releases of Hirsute, those that are made available between this project’s inception at the end of October 2020 and the beta version of April 2021? Previous versions of Ubuntu have, at times, been released in an alpha version. This is no longer the case. Instead, a kind of rolling development version is made available on a daily basis, with the ISO files to be found here: http://cdimage.ubuntu.com/daily-live/current/
The first of the two links should be considered specific for Hirsute Hippo, and will need to be updated as future versions roll around. However, the second link —to daily images— has been stable for some years and, in time, will probably point towards future development versions of Ubuntu – whatever they may be called. (“Irritated Ibis”? Just guessing at this point.)
For all practical intents and purposes, these daily builds can be considered as alpha software. The only departures from standard software development are the fact that new versions are being published on a day-to-day basis (not just at a single point in time), and that the testing process is being extended to all potential users of the system (not just in-house staff or developers).
On to the main question: should you consider downloading, trying out and eventually installing this pre-production software? Well, perhaps, but do it knowing precisely what purpose it has, and which caveats to take into account. Let us start with the latter: • Be aware that things may not work as expected, or even break themselves and other parts of the software stack. The system may fail catastrophically, with no warning, and has the potential to wipe any and all data on your drives. In short, any version of a Ubuntu distribution that is not published specifically as a final, production-ready version should NOT (emphatically NOT) be used on your daily computer, or on any machine that holds data you care about. Period. • Some aspects of the system —which software is present, and how it is configured— may change as it goes through daily builds and beta. So, do not take an alpha version as the final product. Do not bet your money or your time on it. It is just the best you can hope for at the time being, if you need to plan ahead on how you will use this version of Ubuntu when it comes out in its final form.
With that out of the way, you should be considering testing an alpha or daily build version of Ubuntu in the following cases: • If you are developing a piece of software that will need to work seamlessly on the next version of Ubuntu. Testing it on daily builds of the distribution is a great way of ensuring compatibility. Do so frequently, as different versions of the new distributions appear, and also on beta when that comes out. If all goes well, then you can have some confidence your software will work fine on the definitive version on release. Naturally, this is relevant mostly for software developers. • If you have a specific piece of hardware that is known to cause issues under Linux in general, or Ubuntu specifically, being able to test that hardware with daily builds is a great way of ensuring that compatibility is maintained. This may be the case even with consumer-grade hardware, with some graphics chipsets and wifi cards being the most typical offenders. This will be relevant for organizations with specific hardware needs, or even individual users that have problematic equipment.
So, once you have decided you need to try out a daily build, how to do so without putting your computers or data at risk? The first way is actually recommended for software developers, and consists of using a virtual environment such as VirtualBox to boot the ISO file. Anything that goes on within the alpha distribution does so within the tightly controlled virtual environment, and cannot affect files on your computer proper. The distribution to be tested can be reviewed merely as a live distribution, or installed to a (virtual) disk and updated periodically there for more testing.
In the case of Hirsute Hippo, we can see that the daily build I downloaded actually works quite well within the virtual environment. As a side-note, we can see that specific backgrounds for this version have not yet been incorporated as of late January 2021, but will be done later on in the process — one would suppose, with a hippo-inspired theme in substitution of the gorilla.
However, neofetch does confirm we are actually working on the new version of Ubuntu 21.04, and not ye olde gorilla version 20.10:
The second way to test daily builds is on actual physical hardware. This is what you need to do if ensuring hardware compatibility is an issue. Here, there is no way around the fact we need to try out the daily build on an actual computer. Ideally, this computer would be a test machine equipped with the hardware we are nervous about compatibility that is dedicated to testing. Naturally, most individuals can scarcely afford to have such a dedicated computer, though the practice is more relevant in organizations with a large number of similar machines. If your park consists of 60 PC-type desktop computers used by members of your organization for daily work, then having computer number 61 of a similar type in the IT department just to test out new software before putting it on staffers’ machines is something of a must. See it as an insurance policy of sorts.
But even private individuals may have an old laptop lying around unused that, in the worst case, can be reformatted with no loss of data. This is our best option to try out alpha grade software in general, and Ubuntu daily builds in particular. The photo is of an old Acer Aspire 11” laptop I use for these purposes. This is actually the only use I have for it, since both the battery and the internal hard drive connector on the motherboard (SATA connector) are long out of commission.
A more compromised situation arises when you have no other choice but to run alpha-grade software on your daily computer. This is really not ideal. At the very least, make a backup of your data —or several backups— before messing around. Even better: it is good practice to actually physically disconnect your hard drive before proceeding, just to ensure your working environment is not affected. Swapping out your hard drive for another drive that will be used only for testing purposes makes sense, since you will be able to come back to your regular operating system and files by just swapping drives back again. However, it should be stressed that running alpha software on a production computer is never a great idea, and should be avoided if you are not a rather experienced system administrator (and experienced systems administrators will avoid doing so at all costs… which is, actually, all you need to know to avoid making a bad decision).
So, coming back to the main question: should you consider downloading, trying out and eventually installing this pre-production software? By all means, do so — but do it knowing precisely what purpose it has, on an appropriate platform (Virtualbox or a dedicated computer), and making sure there is no danger for your data. Any feedback you can give the developers —by filing bug reports— may be of help to make the distribution better and safer for regular users.
But, if you are at all uncomfortable with what has been laid out in these lines, just stick to regular production releases. It will be good to know that daily builds and beta releases are done, and our favorite distribution is widely tested by a variety of people in different situations and on a diversity of platforms before software gets to your hands. Some would in fact argue that this is precisely the main strength of open-source software in the first place.