Version lifecycle/es

MediaWiki opera en un modelo de desarrollo de "integración continua", donde los cambios al software son puestos al instante en los sitios de Wikimedia como Wikipedia, regularmente.

En teoría, las nuevas versiones principales se emiten sobre una base de medio año, y las ramas de liberación continúan recibiendo actualizaciones de seguridad para un máximo de un año a partir del primer lanzamiento. Debido a limitaciones de tiempo y la rápida refactorización del código base, no podemos usar versiones obsoletas para siempre, y las actualizaciones de seguridad y críticos no se aplican a las versiones que han llegado al final de su estado de vida.

Los desarrolladores de MediaWiki, incluyendo el director de lanzamientos, Tim Starling, recomiendan fuertemente que los wikioperadores se suscriban a la lista de mail mediawiki-announce, que recibe notificaciones de todos los lanzamientos, y asegura que su wiki corra la versión más actualizada del software posible. Esos anuncios son también posteados en mediawiki-l y wikitech-l.

Versiones actuales y sus periodos de término de vida
Versiones incluidas en el cuadro anterior están marcados como obsoletos, no recibirán ningún parches de seguridad. Pueden contener vulnerabilidades críticas de seguridad y otros virus importantes, entre ellos la amenaza de una posible pérdida de datos y/o corrupción. El administrador de la versión también ha emitido una fuerte recomendación de que solo versiones mencionadas anteriormente como current version o legacy version se debe utilizar en un entorno de producción.

Política de lanzamiento

 * Cada punto de liberación incluirá archivos i18n actualizados, así como las correcciones de errores. No hay nuevas características estarán de vuelta con puertos para señalar las emisiones y el apoyo no incluye extensiones en general, véase más adelante (por ejemplo, no es compatible con la corriente LTS).
 * Un importante lanzamiento se hará cada seis meses.
 * Una liberación de apoyo a largo plazo (LTS en inglés) se hará cada dos años. Habrá una superposición de un año en apoyo LTS. Por ejemplo, 1,23 fue apoyado hasta mayo de 2017. 1.27 fue lanzado el año anterior por lo que la gente tenía que esté disponible como un LTS para pasar a un año y hacer la transición.
 * Notas de la versión seguirán siendo la base para ver qué ha cambiado. Debido a la naturaleza de un proyecto por voluntarios, no es posible decir con certeza qué sucederá con la voluntad en los próximos 6-12 meses.
 * Para mitigar el problema de las notas de la versión, vamos a publicar una lista de nuevas características en la próxima LTS relativa a la última LTS seis meses antes de que salga. Esto significa que alrededor de la época en que salió 1,26, se hizo un anuncio de la versión 1,23, dando a conocer los cambios que se esperan de la versión 1.27.

Cronograma de lanzamiento
Esta linea de tiempo es un programa para lo que debe suceder antes del lanzamiento de una nueva versión. La fecha de la liberación real se da aquí como T ("tiempo" de la liberación) y el sufijo -# (para el "número de semanas antes de su liberación").

Extension lifecycle management
Most MediaWiki installation include a significant number of extensions (WMF MediaWikis often around 80 extensions). Managing the maintenance bug fixing of extensions and choosing the right version of an extension in cases where the HEAD development version relies on features not yet available in stable or oldstable MediaWiki core, is a major challenge for all maintainers of MediaWiki installations.

Extension maintainers are therefore strongly encouraged to maintain a git tag or branch for their version corresponding to the release tag the stable and oldstable version. An initial version, that simply points to the state of the code at the time of the release may be created centrally. However, it is the responsibility of the extension maintainer to fix bugs not only in HEAD but also in the oldstable and stable versions. If the extension works with all of oldstable, stable and HEAD, this requires only to update the tags. However, if some changes are specific to later versions, the lifecycle rule require that branches are created and individual merges of the bugfix to each branch be made.

The goal of these rules is that people or organizations installing MediaWiki can rely on installing the newest release of a version and matching extensions by a simple method, e.g. for 1.20.x core by referring to REL1_20 in git.

Enlaces externos

 * Generators on WikiApiary - Statistics about the use of different versions of MediaWiki.