Versiones de Moodle

De MoodleDocs

Nota: Esta es una traducción de una página de la documentación para desarrolladores (Developer docs), que se considera particularmente importante, y que en su versión original se actualiza frecuentemente. Por ello, se le recomienda que revise la página original en idioma inglés: Moodle versions.

Nota: Pendiente de Traducir. ¡Anímese a traducir esta página!.     ( y otras páginas pendientes)

Versiones y ramas (branches) de Moodle

Entender el esquema para nombrar las versiones de Moodle le ayudará al usar nuestros repositorios para obtener su código (por ejemplo, curante una Actualización). El conocer la versión correcta también es muy útil al reportar problemas (bugs) en nuestrotracker.

Esquema de las ramas del código fuente de Moodle, versiones y niveles de madurez


Versiones principales (major) y menores

Los números de versión de Moodle consisten de tres números separados por un punto; por eemplo 1.9.11 or 2.0.2. Los primeros dos números, como 1.9 o 2.0, representan la versión principal (major version). El tercer número distingue entre las versiones menores ( minor versions) dentro de la misma versión principal. Cuando selibera una nueva versiónprincipal, inicia conel mnúmero de versión menor de 0 (cero). Así, Moodle 2.0.1 fue la primera actualización menor de Moodle 2.0.0.

Generalmente, el Cuartel General de Moodle mantiene las dos versiones principales más recientes, con la notable excepción de Moodle 1.9 que fue soportada por mucho tiempo.

Versiones y ramas (branches)

Moodle developers use the source code management (SCM) system 'Git' to track changes in the code. As in many SCMs, the history of changes in Git is represented via so called branches. You can consider a branch as a labeled sequence of source code changes.

There is a branch created for every major version of Moodle. All Moodle 1.9 versions come from MOODLE_19_STABLE branch and all Moodle 2.0 versions come from MOODLE_20_STABLE branch. There is also a main development branch called master that holds the changes for the next future version. At the moment, the changes on the master branch will be included in Moodle 2.1 release.

Liberaciones (releases)

Since version 2.0, Moodle aims to release the new major version every six months or so. See https://docs.moodle.org/dev/Roadmap page for a schedule.

Minor versions are released every two months, including both bugs and security issues fixed. Ve ala página de Versiones para más detalles e información.

In the meantime between two releases, Moodle HQ team publish updates for the most recent stable versions. These updates are published every week, usually on Wednesday. They are known as weekly builds and are identified by a small increment in the version and a build date like 20140422. That is a timestamp in a form YYYYMMDD when the weekly build was released. These weekly builds are labelled with a version number suffixed with a plus sign. So 2.6.2+ denotes some weekly build extending the 2.6.2 minor release.

Niveles de madurez del código fuente

During its life cycle, the Moodle code branch goes through several maturity levels.

  • At the beginning, the branch is considered as being in alpha state. During this period, new features are added to the branch. API and database structure may change as needed. These versions are intended mainly for developers as nothing is guaranteed (the version may or may not install and upgrade, for example).
  • When it is decided that no new feature will be added to the branch (so called feature freeze), beta maturity level is reached. Developers focus on testing, bugs fixing and stabilizing the branch.
  • When all known critical and blocker bugs are fixed and no new bugs are reported for some time of testing, a preview version of the branch can be released as so called release candidate. When the first release candidate version (RC1) has been published, release candidate maturity level is reached. During this period, several RC versions can be issued, for example 2.1RC1, 2.1RC2, 2.1RC3 etc.
  • Finally, the new major version is released and the branch reaches stable maturity level. From now on, the database structure and API do not change on this branch. A corresponding MOODLE_xx_STABLE is created and minor versions and weekly builds are created off it.

Números de versión

Each plugin's version.php file can specify a minimum version of Moodle required for the plugin to work, for example

$plugin->version = 2011080200;
$plugin->requires = 2011070101;

For the version numbers related to each release, see the Versiones page.

Cómo se incrementan los números de versión en el núcleo

In Moodle core, when we branch from master, we also branch version numbers. That means that no version number in a stable branch should ever be higher than on master (or a higher branched version).

The version number is constructed as YYYYMMDDRR.XX.

  • YYYYMMDD is the date of the branching point. If on master, a branch has not happened, so it should be set to the current date. Otherwise it should not be changed (left as it was)
  • RR is the release increment. This is the incremental counter for changes on a single branch or day (if in master).
  • XX is the micro increment. This 'fraction increment' was introduced when after we realised that it might be possible to have more than 99 upgrade steps on a stable branch (in the RR increment). It tends to only be used in the main version number file.

Reglas para las ramas estables

  • If a 'micro increment' (.XX) exists
    • Developers should only increment the 'micro increment' 'XX'
    • The integration team reserve the use of 'RR' to branch between point releases.
  • If a 'micro increment' (.XX) does not exist
    • Please increment the RR.

>Reglas para master

  • You must increment the whole version number to the current date.
  • So, on 6th February 2013, the version number is set to: 2013020600.00

Porqué ramificamos las versiones

Imagine the following problem scenario:

  1. Moodle 2.4 is released, mod_forum is set to version 2012120300
  2. In master only, Eloy updates drops a DB field in an upgrade step and sets the moodle version to 2013010100
  3. In 2.4.1 and master, Dan fixes a problem in a capability definition and sets the version in both branches to 2013010200. (note: Oh no! we've incorrectly changed the branching date for the entire future 2.4.x!)
  4. Moodle 2.5 is released and the mod_forum is set to version 2013060100
  5. After the release, Helen updates her Moodle from Moodle 2.4.1 to 2.5.

The implications of Dan changing the 2.4.x version to 2013010200 in step 3, means that Eloy's upgrade step from 2 will never get run. This is very bad!

I know that there are no changes between STABLE and master, can I set the version number as the same?

Not for core plugins, sorry. There are too many developers working on the same code and it prevents accidents if we avoid doing this for core.

Vea también