Ciclo de vida de las versiones
| MediaWiki |
|---|
|
| Versiones antiguas |
| Ciclo de vida de las versiones |
MediaWiki opera en un modelo de desarrollo de «integración continua», donde los cambios en el software se despliegan directamente en los sitios de Wikimedia, tales como Wikipedia, de forma regular.
En teoría, las nuevas versiones principales se liberan cada seis meses, y las ramas de estas versiones continúan recibiendo actualizaciones de seguridad por un máximo de un año a partir de la primera liberación. Debido a limitaciones de tiempo y a la rápida refactorización del código base, no podemos mantener versiones obsoletas para siempre y las actualizaciones de seguridad y las actualizaciones críticas no se aplican a las versiones que han llegado al final de su ciclo de vida.
El administrador de la versión recomienda encarecidamente que los operadores de la wiki se suscriban a la mediawiki-announce, para que reciba notificaciones de todas las versiones y se asegure de que su wiki ejecuta la versión más actualizada posible del software. Estos anuncios también se publican en mediawiki-l y wikitech-l.
Versiones y su fin de vida
| Versión | Estado | Liberación | Fin de vida |
|---|---|---|---|
| 1.44.x | versión futura | ||
| 1.43.x (LTS) | versión futura con soporte a largo plazo | ||
| 1.42.x | versión actural estable | ||
| 1.41.x | versión heredada | ||
| 1.40.x | versión obsoleta | ||
| 1.39.x (LTS) | versión actual con soporte a largo plazo | ||
| 1.38.x | versión obsoleta |
Las versiones incluidas en el cuadro anterior que estén marcadas como obsoletas, así como las versiones que no figuran en la lista, no recibirán ningún parche de seguridad. Pueden contener vulnerabilidades críticas de seguridad y otros fallos importantes, entre ellos la posibilidad de pérdida y/o corrupción de datos. El gestor de versiones también ha emitido una fuerte recomendación de que solo las versiones listadas arriba como “versión actual” o “versión heredada con soporte a largo plazo” (LTS) se utilicen en un entorno de producción. Esto incluye también todas las versiones más antiguas que la versión más antigua que figura en la lista. Pueden contener vulnerabilidades críticas de seguridad y otros errores importantes, incluida la amenaza de posible pérdida de datos y/o corrupción. The release manager has also issued a strong recommendation that only versions listed above as the current “stable version”, "legacy version" or “long-term support version” be used in a production environment.
- Versión alfa
- Desarrollo de lanzamiento
- Versión estable
- Soporte a largo plazo - (LTS)
Política de liberaciones
- Cada punto de liberación incluirá los archivos i18n actualizados así como cualquier corrección de errores. No se incluirán nuevas características en las versiones portadas a un punto de liberación y, en general, el soporte no incluye necesariamente las extensiones y los skins agrupados.
- Se realizará una liberación importante cada seis meses.
- A minor release (including security patches, message translation back-ports, and general bugfixes) will be made every quarter.
- Cada dos años se realizará una liberación con soporte a largo plazo (long-term support release o LTS en inglés). Habrá una superposición de un año en el soporte de LTS. Por ejemplo, 1.23 tiene soporte hasta mayo de 2017. El año anterior, se liberó la 1.27, de forma que estaba disponible como LTS a la que migrar, con un año para hacer la transición.
- Las notas de la versión seguirán siendo la base para ver lo que ha cambiado. Debido a la naturaleza de un proyecto impulsado por voluntarios, no es posible decir con certeza lo que sucederá en los próximos 6 a 12 meses.
Cronograma de liberaciones
Esta línea de tiempo es un cronograma de lo que debe suceder antes de la liberación de una nueva versión. La fecha de la liberación real se da aquí como T («tiempo» hasta la liberación) y el sufijo -# (para el «número de semanas que faltan hasta la liberación»).
| Programación relativa | Tarea |
|---|---|
| T - 7 | Anuncia que la rama de la versión se creará en una semana. Pide a la gente que se asegure de que todo lo necesario para completar las funciones en curso se fusionen antes de esa fecha. Crea «MW-X.XX-release» en Phabricator. |
| T - 6 | Crea la rama del núcleo y todas las extensiones en Gerrit. |
| T - 5 | Aplica la etiqueta X.XX-rc.0 y libera la versión candidata inicial. |
| T - 4 | Recoge todos los informes de error y los resume en la lista de correo. |
| T - 3 | Aplica la etiqueta X.XX-rc.1 y libera la segunda versión candidata. En este punto, todas las nuevas extensiones que se propongan para agregar al tarball deberían estar en él. No se realizan cambios de extensión después de este punto. |
| T - 2 | Recopila todos los nuevos informes de error, fusiona las correcciones, elimina las nuevas funciones incompletas incluidas accidentalmente, aplica la etiqueta X.XX-rc.2 y libera la tercera versión candidata. |
| T - 1 | Repite el paso anterior, aplica la etiqueta X.XX-rc.final y procede a la liberación. No se aceptan backports después de este punto. |
| T | ETIQUETA el repositorio con X.XX y realiza la liberación. |
Gestión del ciclo de vida de las extensiones
La mayoría de las instalaciones de MediaWiki incluyen un número significativo de extensiones (las wikis de Wikimedia a menudo ofrecen alrededor de 140). Administrar la corrección de errores de mantenimiento de las extensiones y elegir la versión correcta de una extensión en los casos en que la versión de desarrollo a la cabeza se basa en características que aún no están disponibles en el núcleo de MediaWiki estable o antiguo, puede ser un desafío. 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 can be challenging.
Por lo tanto, se recomienda encarecidamente a los mantenedores de extensiones que mantengan las ramas del git para cada versión de la extensión correspondiente a una versión de MediaWiki.
(véase Compatibility#MediaWiki extensions para más detalles.)
En las extensiones alojadas en los repositorios git de Wikimedia, dichas ramas (con nombres como REL1_30 para MediaWiki 1.30) se crean automáticamente desde el master cuando se ramifica una nueva versión de MediaWiki (en el supuesto de que el master de la extensión sea compatible con el master de MediaWiki en todo momento).
Sin embargo, es preferible que el mantenedor de la extensión corrija los errores no solo en la cabecera sino también en las versiones estable y antigua (realizando una copia de seguridad de la corrección en las ramas antiguas si es necesario).
El objetivo de estas reglas es que las personas u organizaciones que instalan MediaWiki pueden confiar en instalar la versión más reciente de una versión y hacer coincidir las extensiones con un método simple, por ejemplo, para el núcleo 1.20.x haciendo referencia a REL1_20 en git.
It avoids tarballs and zip files with non-relevant and unpredictable names.
Véase también
- Compatibility information for MediaWiki, most importantly PHP and MySQL
- Stable interface policy
- Estadisticas en WikiApiary - Estadísticas sobre el uso de diferentes versiones de MediaWiki.