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 publican 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 del primer lanzamiento. Sin embargo, 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 | Lanzamiento | Fin de vida |
|---|---|---|---|
| 1.44.x | versión futura | ||
| 1.43.x (LTS) | versión actual con soporte a largo plazo | ||
| 1.42.x | versión actural estable | ||
| 1.41.x | versión obsoleta | ||
| 1.40.x | versión obsoleta | ||
| 1.39.x (LTS) | versión heredada con soporte a largo plazo | ||
| 1.38.x | versión obsoleta |
Las versiones marcadas en el cuadro anterior como obsoletas, así como las versiones que no figuran en la lista, no recibirán ningún parche de seguridad. 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. 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 con soporte a largo plazo” (LTS) se utilicen en un entorno de producción.
- Versión alfa
- Desarrollo de lanzamiento
- Versión estable
- Soporte a largo plazo - (LTS)
Política de lanzamiento
- Cada versión puntual incluirá los archivos i18n actualizados así como corrección de errores. No se integrarán funcionalidades nuevas en versiones puntuales anteriores y, en general, el soporte no incluye necesariamente las extensiones y apariencias integradas en general.
- Se lanzará una versión mayor cada seis meses.
- Se lanzará una versión menor (incluyendo parches de seguridad, retroportación de mensajes traducidos y correcciones de errores en general) cada tres meses.
- Se lanzará una versión con soporte a largo plazo (long-term support release o LTS en inglés) cada dos años. Habrá un solapamiento de un año en el soporte de LTS. Por ejemplo, 1.23 tuvo soporte hasta mayo de 2017. El año anterior, se lanzó la 1.27, de forma que está disponible como LTS a la que migrar, con un año para hacer la transición.
- Las notas de 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 versiones
Esta línea de tiempo es un cronograma de lo que debe suceder antes del lanzamiento de una nueva versión. La fecha real de lanzamiento se da aquí como T («tiempo» o fecha del lanzamiento) y el sufijo -# (para el «número de semanas que quedan para el lanzamiento»).
| 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 lanza 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 lanza 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 lanza la tercera versión candidata. |
| T - 1 | Repite el paso anterior, aplica la etiqueta X.XX-rc.final y procede al lanzamiento. No se aceptan retroportaciones después de este punto. |
| T | ETIQUETA el repositorio con X.XX y haz el lanzamiento. |
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.
Por lo tanto, se recomienda encarecidamente a los mantenedores de extensiones que mantengan una rama de 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.
Evita que haya tarballs y archivos zip con nombres irrelevantes e impredecibles.
Véase también
- Información de compatibilidad para MediaWiki, particularmente PHP y MySQL
- Política de interfaz estable
- Estadisticas en WikiApiary - Estadísticas sobre el uso de diferentes versiones de MediaWiki.