ROSA Fresh release policy

From Rosalab Wiki
Revision as of 11:49, 21 April 2017 by Vladimir.potapov (Talk | contribs) (Created page with "== Platforms == The ROSA FRESH distribution is based on the software platforms, their development and releases. As a rule, the platforms are released twice a year with a 'year...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


The ROSA FRESH distribution is based on the software platforms, their development and releases. As a rule, the platforms are released twice a year with a 'year.half year' numbering. The platforms 2012.0 2012.1 2014.1 2016.1 were released based on this rule. The platform includes the programs repositories with the packages of all kinds of programs. The repositories of the platform have three brancnes: 1) 'release', which is a fixed state of the packages shortly before the release itself 2) 'updates' which includes the updated packages and 3)'testing', the updated packages waiting to be tested before going to 'updates' repo

The releases

Based on the software platfors the ISO images of the distributions are released/ As a rule, such distributions are released once in a half-year and are numbering as follows: <graphical environment name>R<number>. The distributions KDE.R8 and GNOME.R8 were released based on this rule. Within the one software platform, the ROSA FRESH releases are just repositories in their current state, built up into ISO images. The releases R1-R3 for example included the packages from the 2012.1 platform repositories, and R4-R8 the 2014.1 platform repositories. The KDE desktop environment is the main and most stable ROSA environment.

The order of the updates

Within the one platform the user programs updates of the ROSA FRESH are performed automatically (that's why it is called Fresh). Users who have installed the ROSA R4, could easily upgrade their systems to the R5, R6, R7 and up to the R8 version. But we recommend installing from scratch using the latest ISO images, since we test only the updates from latest previous version to the current one. The main system components such as gcc, glibс ec are updated only within the new platform release. The automatic upgrade from one platform to another is not supported, but the repositories of the previous platform are kept working and are functional even after the new platform release.

Updates policy

The general policy for the updates follows the rule of keeping the updates as smooth as possible, with no interface changes and no functional regressions. The interface changes are allowed only during the platform updates, i.e. during the installation from the release ISO image. If the ISO image software set or the default user settings were changed, those updates will not come into already installed systems. The QA team is testing packages from the 'main', 'non-free' and 'restricted' repositories in order to exclude any update regressions. The new updates come to the 'tested' repo first, and after the test have been performed they go into the main repos. The final platform release (as was R8 for 2014.1, for example) comes very stable and has 2 years support using the conservative updates policy.

Updates support

While testing the updates candidates the QA team uses two updates policies, the Standard and the Conservative. The Standard policy means that the updates serve to improve the current platform functionality, and in that case the QA team approves the package update if it contains no errors and no regressions. One month before the release date the policy is changed to the Conservative, i.e. aimed to the errors fixing and making the repos more stable, and in that case the QA team approves only the bugfixes or important functionality changes (in this case the maintainer has to prove that the update is really needed). The same policy applies to the already released platform.