Joomla ha sido diseñado y construido, ya desde su núcleo, como una ayuda a las personas. Está centrado en la simplicidad y facilidad de uso. Estas son las razones que, de alguna manera, nos han acercado al desarrollo de Joomla.

Objetivos

• Continuar ofreciendo una plataforma estable y confiable para nuestros usuarios actuales y futuros.
• Hacer que la innovación esté disponible de una manera más fácil para usuarios y desarrolladores.
• Hacer que sea más fácil para los desarrolladores contribuir con código al proyecto en cualquier momento.

Hay cinco principios importantes en la estrategia de desarrollo de Joomla dirigida a la consecución de esos objetivos:

1. mantener un núcleo estable;
2. versiones de software predecibles, incrementales;
3. fuerte compromiso de compatibilidad con versiones anteriores;
4. una política de seguridad sólida;
5. y un proceso de desarrollo abierto.

Mantener un núcleo estable

Es fundamental para nuestra misión que el núcleo contenga siempre una versión probada y estable del código base, que pueda estar lista para su lanzamiento en poco tiempo. Para asegurarse de que el núcleo tiene siempre un acceso a escritura estable, sólo se le concede el acceso, a un número limitado de personas de confianza y disciplinadas.
El núcleo representa la versión actual de desarrollo, funcionamiento o la versión más actualizada del software. Cuando las funciones o problemas se están "trabajando" debería hacerse en un dominio o un sistema separado totalmente del estable hasta su finalización. Los cambios sólo deben estar comprometidos con el núcleo cuando están completos y haber superado todas las pruebas automatizadas. La actualización se puede hacer a través de una fusión entre ramas o a través de un archivo en forma de parche, dependiendo de la magnitud del cambio.

Requisitos para ser incluido en el núcleo.

Hay algunos requisitos que se deben cumplir antes de que los cambios se puedan considerar para su inclusión en el núcleo. Estas medidas ayudan a asegurar que el núcleo mantenga siempre un estado estable.

Satisfacer a la comunidad de Joomla! “Normas de Codificación”.

Los estándares de codificación existen para mantener el código consistente, fácil de leer y de mantener. Antes de que las contribuciones de código se incluyan en el núcleo deben cumplir con los estándares de codificación de Joomla que se describen en detalle en la documentación del wiki.

Pasar todas las pruebas automatizadas.

Las pruebas automatizadas se utilizan para aislar las partes específicas o características del software y asegurarse de que se comporten correctamente. El proyecto Joomla mantiene “pruebas unitarias” para las clases y métodos, así como “pruebas de funcionalidad” del sistema para diversas aplicaciones. Antes de que las contribuciones de código se incluyan en el núcleo deben pasar todas las pruebas automatizadas para que podamos estar razonablemente seguros de que el núcleo se mantiene estable y confiable.

Proporcionar pruebas automatizadas para todas las clases de la API y métodos nuevos

Los nuevos métodos o clases añadidas al framework de Joomla, conocido como Joomla Platform, deben ir acompañados/as de pruebas unitarias de trabajo para verificar su correcto comportamiento. Esto sirve para ayudar a garantizar que no sólo funciona el código actual, sino que los futuros cambios no harán que el núcleo sea inestable. Las pruebas adecuadas del sistema se deben crear para verificar el comportamiento que se espera.

Proporcionar la documentación básica para todas las nuevas incorporaciones al código base

Para mantener las características y sistemas añadidos al código base así como para ayudar a asegurar la capacidad de mantener nuestro principio de compatibilidad con versiones anteriores, es necesario añadir alguna documentación básica. Esta documentación es necesaria para las nuevas clases de la API, los métodos o la lógica de la nueva aplicación cuando se agrega al núcleo. Si está escribiendo una nueva clase o método, describa para que se supone que se utiliza y por qué existe y añada también un par de breves ejemplos de su uso. Por las características de la aplicación, describir la incorporación o descripción de cada diseño y el uso previsto.

Lanzamientos predecibles, Software incremental

Una versión de software es la distribución de código de software, documentación y materiales de apoyo. La estrategia del proyecto Joomla para las versiones de software se inspira, en gran medida, en el proceso de versiones del proyecto Ubuntu basadas en el tiempo, que también lo tomó prestado, en gran medida, del proyecto GNOME.

Estrategia de las versiones

Los identificadores de versión de Joomla siguen una convención numérica de tres niveles donde los niveles se definen por relevancia de cambio. Dependiendo de la importancia del cambio entre una versión y la versión anterior se designará como uno de esos tres niveles: mayor, menor o mantenimiento.

Principal. Menor (Mantenimiento)

Si la liberación se designa como importante el primer número en el identificador de versión se incrementa y los números restantes se ponen a cero como, 1.0.0 o 2.0.0. Si la versión es una versión menor, se incrementa el segundo número y el último se mantiene a cero como, 1.5.0 y 1.6.0. Para la liberación de una versión de mantenimiento, se incrementa el último número como, 1.6.1 y 1.6.2.

Gran lanzamiento o mayor

Para que una versión pueda ser clasificada como mayor o principal ha de incluir un alto grado de cambio en comparación con la versión anterior. Generalmente esto implica un cambio masivo en la arquitectura y/o cambios en el interfaz de usuario. Los cambios sustanciales en el modelo de datos subyacentes también pueden ser causa de una liberación para ser identificada como importante.

Versión secundaria o menor

En las versiones secundarias ha de haber un alto grado de continuidad, tanto en la arquitectura, como en el modelo de datos entre la liberada y la versión anterior, mientras que proporciona mejoras en la funcionalidad o alguna novedad.

Versión de mantenimiento

En la versión de mantenimiento solamente se incluyen corrección de errores, a las vulneraciones de seguridad y problemas de usabilidad. No se añaden nuevas funcionalidades, a menos que esta resuelva un problema de la versión anterior que se debe de solucionar antes de la siguiente versión secundaria.

Asignación de la versión

Una vez que un lanzamiento de una versión se considera completa y está en camino a la estabilización, la evaluación se llevará a cabo sobre la base de los cambios de la versión anterior para determinar su clasificación como mayor, menor o mantenimiento.

Ciclo de Vida de los lanzamientos

El ciclo de vida de las versiones del software se compone de distintas fases y etapas, que expresan la madurez del software a medida que se avanza desde la planificación hasta el desarrollo del lanzamiento y el soporte. No todos los lanzamientos pasará por todas las posibles fases. A modo de ejemplo, en la mayoría de las versiones de mantenimiento se omiten todas las fases hasta la etapa de versión candidata, porque los cambios sobre la versión anterior son mínimos.

Etapas del software

En el lanzamiento del software hay cuatro etapas principales en el ciclo de vida de Joomla: alfa, beta, release candidate, y la de disponibilidad general.

Alfa

La etapa alfa significa que hay una nueva tecnología en el software y que está preparado para probar. Los paquetes de software marcados como alfa no se presentan completos y no son adecuados para entornos de producción.

Beta

Una vez que el lanzamiento ha alcanzado la etapa beta se considera que ha llegado a su madurez. Al igual que los paquetes de software marcados como  alfa, los que están marcados como beta no se consideran adecuados para entornos de producción. Están destinados a ser probados a fondo por cuestiones de compatibilidad hacia atrás, así como encontrar problemas de seguridad y estabilidad.
Nota: Generalmente, no se añaden nuevas características después de la etapa beta, a menos que sean características para corregir las implementaciones defectuosas o comportamientos que falten, o se encuentren en las pruebas de compatibilidad con versiones anteriores.

Release Candidate (Candidata al lanzamiento)

Cuando una versión esta completa y ha sido probada a fondo se puede declarar como que ha llegado a la etapa Release Candidate (RC) de la etapa. Los paquetes marcados como candidatos a la liberación se consideran completos y adecuados para entornos de producción. Tienen potencial para ser un producto, listo para la liberación y la disponibilidad general a menos que surjan problemas críticos.

Disponibilidad General

La etapa de disponibilidad general (GA) indica que la liberación es muy estable y adecuada para su distribución masiva y de uso por los usuarios finales.

Fases de lanzamiento

Hay tres fases distintas en el ciclo de vida del software de Joomla. A todos los efectos, Estas fases comienzan en el punto donde acaba de salir la liberación en la etapa de disponibilidad general como se describió anteriormente.

Mantenimiento

Después de seis semanas de una liberación, se alcanza la etapa de disponibilidad general (GA), todavía el principal objetivo es el de producción. la responsabilidad del Joomla Bug Squad y otros equipos se basa en encontrar y corregir problemas que puedan aparecer en la versión estable. Sólo se aceptan cambios para garantizar la estabilidad ( por ejemplo no se acepta código que aporte funcionalidades nuevas). Sólo después de exhaustivas pruebas de estabilidad para la nueva versión, son aceptados los cambios para su inclusión en el tronco. Si es necesario se pueden lanzar liberaciones de mantenimiento durante esta etapa. Al final de la fase de mantenimiento de la versión, sólo se actualiza en el caso de encontrar vulnerabilidades de seguridad hasta el final del ciclo de vida estipulada.

Función de combinación

La transición de la fase de mantenimiento a la de función de combinación, marca un cambio en el enfoque de los esfuerzos de desarrollo de la versión estable actual a la siguiente versión. Durante doce semanas después de la finalización de la etapa de mantenimiento, se pueden incorporar nuevas características provenientes, tanto de ramas cómo de “parches”, en el tronco. En este momento el paquete ya no representa la versión actual estable, sino la próxima versión.
Durante este tiempo, la liberación alcanzará la fase alfa y uno o más paquetes alfa pueden estar disponibles para previsualizar nuevas características o tecnologías que se han fusionado en el tronco.
Nota: El trabajo de desarrollo en las ramas pueden hacerse (y se le anima a que se haga) en cualquier momento del ciclo de vida de desarrollo y no se limita a la etapa de combinación. Esto es sólo la etapa del ciclo de vida en que tales cambios se pueden combinar en el paquete para la próxima versión.

Pruebas de lanzamiento

El comienzo de la “etapa de pruebas de liberación” está marcado por la consecución de la etapa beta. Durante esta etapa, que debe durar alrededor de ocho semanas, la concentración de los equipos de producción se desplaza a la realización de pruebas exhaustivas de la liberación. Los nuevos paquetes están disponibles cada dos semanas para ser comprobados por los usuarios finales a través de la liberación de paquetes de pruebas beta. También se acaban en esta etapa las pantallas de ayuda en línea y las traducciones de las definiciones. Es importante que todos los desarrolladores de extensiones comprueben su software durante esta fase de compatibilidad hacia atrás para que puedan ser resueltos los problemas antes de la etapa de disponibilidad general (GA).
La etapa de disponibilidad general marca el final de la etapa de prueba de liberación. Paquetes finales para el lanzamiento se construyen y distribuyen, siempre acompañado con anuncios y / o comunicados de prensa. Después de esta fase, el ciclo se reinicia con la fase de mantenimiento.

Esperamos que el mes que viene salga la parte 2ª. ↑