Control de versiones
¿Cómo funciona el sistema de versiones de Piwigo? ¿Cuáles son las diferencias entre las versiones 1.3.1 y la 1.4.0?
Versiones
Una versión es una especie de captura/fotografía/instantánea del código en un determinado momento, por tanto, es el estado en el que se encuentra Piwigo en un instante dado dentro de su trayectoria de desarrollo o modificación. Por ejemplo, si se lanza la versión 1.3.1, se cierra y no sufre modificación alguna una vez cerrada. Automáticamente se genera una nueva versión 1.3.2. Si la instantánea se tomó en la versión 1.3.1, ésta corresponderá a la rama 1.3. Una rama se desarrolla a través de la mejora y corrección de errores pero no se determina únicamente teniendo en cuenta la inclusión de nuevas funciones: la versión 1.3.3 no aportará funcionalidades extra frente a la versión 1.3.0. Únicamente se mejora el código para las funciones existentes así como para la corrección de errores.
Ramas
Representación jerárquica de ramificaciones y versiones de Piwigo hasta la fecha:
+-------+
| trunk |
+-------+
|
| 1.3.0RC1 r158 2003-09-21
| 1.3.0RC1 r181 2003-10-05
| 1.3.0 r205 2003-10-12
|
+-------- branch 1.3 ----------+
| | 1.3.1 r379 2004-02-28
| | 1.3.2 r448 2004-06-29
| | 1.3.3 r551 2004-10-03
| 1.4.0RC1 r683 2005-01-09 |
| | 1.3.4 r713 2005-01-20
| 1.4.0RC2 r718 2005-01-21
| 1.4.0RC3 r741 2005-02-13
| 1.4.0 r750 2005-03-12
|
+-------- branch 1.4 ----------+
| | 1.4.1 r790 2005-05-14
| 1.5.0RC1 r871 2005-09-21
| 1.5.0RC2 r907 2005-10-22
|
+-------- branch 1.5 ----------+
| | 1.5.0 r929 2005-11-08
| | 1.5.1 r978 2005-12-10
| | 1.5.2 r989 2005-12-25
|
+--------- branch 1.6 ---------+
A | | 1.6.0RC1 r1263 2006-04-24
L | | 1.6.0RC2 r1319 2006-05-23
L | | 1.6.0 r1432 2006-07-04
I | | 1.6.1 r1482 2006-07-18
G | | 1.6.2 r1599 2006-11-09
A | Alligator1 r1709 2007-01-10
T | Alligator2 r1787 2007-02-07
O | 1.7.0RC1 r1825 2007-02-15
R | 1.7.0RC2 r1938 2007-04-06
|
+-------- branch 1.7 ----------+
B | | 1.7.0 r1999 2007-05-05
U | | 1.7.1 r2193 2008-01-24
T | | 1.7.2 r2457 2008-07-24
T | Butterfly1 r2492 2008-08-31 |
E | Butterfly2 r2522 2008-09-12 |
R | | 1.7.3 r2762 2008-09-16
F | 2.0.0RC1 r2615 2008-09-27
L | 2.0.0RC2 r2658 2008-10-04
Y |
+-------- branch 2.0 ----------+
C | | 2.0.0RC3 r2732 2008-10-13
O | | 2.0.0RC4 r2866 2008-11-12
L | | 2.0.0 r3153 2009-02-15
I | | 2.0.1 r3210 2009-03-17
B | | 2.0.2 r3276 2009-05-06
R | | 2.0.3 r3526 2009-07-05
I | | 2.0.4 r3868 2009-09-19
| | 2.0.5 r4016 2009-10-11
| | 2.0.6 r4209 2009-11-05
| | 2.0.7 r4533 2009-12-19
| | 2.0.8 r4754 2010-01-26
| | 2.0.9 r5013 2010-03-01
| 2.1.0RC1 r5410 2010-03-27 |
| 2.1.0RC2 r5848 2010-04-14 |
| 2.1.0RC3 r6015 2010-04-30 |
| | 2.0.10 r6117 2010-05-11
|
+-------- branch 2.1 ----------+
| | 2.1.0 r6202 2010-05-18
| | 2.1.1 r6347 2010-05-25
| | 2.1.2 r6630 2010-06-29
| | 2.1.3 r6914 2010-09-14
| | 2.1.4 r7506 2010-10-30
| | 2.1.5 r7612 2010-11-04
| 2.2.0RC1 r8811 2011-01-20 |
| | 2.1.6 r8857 2011-01-24
| 2.2.0RC2 r9116 2011-02-08
| 2.2.0RC3 r9373 2011-02-25
| 2.2.0RC4 r9618 2011-03-11
| 2.2.0 r9955 2011-04-01
|
+-------- branch 2.2 ----------+
| | 2.2.1 r10437 2011-04-17
| 2.3.0beta1 r11186 2011-06-01 |
| | 2.2.2 r11198 2011-06-01
| | 2.2.3 r11288 2011-06-10
| 2.3.0beta2 r11591 2011-07-01 |
| | 2.2.4 r11755 2011-07-15
| 2.3.0beta3 r11847 2011-07-29 |
| | 2.2.5 r12024 2011-08-31
| 2.3.0RC1 r12040 2011-09-02
| 2.3.0RC2 r12134 2011-09-12
|
+-------- branch 2.3 ----------+
| | 2.3.0 r12345 2011-10-04
| | 2.3.1 r12582 2011-11-07
| | 2.3.2 r12766 2011-12-19
| 2.4.0beta1 r12829 2012-01-02 |
| 2.4.0beta2 r13020 2012-02-02 |
| | 2.3.3 r13160 2012-02-14
| 2.4.0RC1 r13480 2012-03-06 |
| 2.4.0RC2 r13883 2012-03-06 |
| | 2.3.4 r13969 2012-04-08
| 2.4.0RC3 r14584 2012-04-30 |
| | 2.3.5 r15795 2012-06-16
|
+-------- branch 2.4 ----------+
| | 2.4.0 r15936 2012-06-22
| | 2.4.1 r16335 2012-07-03
| | 2.4.2 r17150 2012-07-26
| | 2.4.3 r17170 2012-07-27
| | 2.4.4 r18273 2012-09-26
| | 2.4.5 r18699 2012-10-19
| 2.5.0beta1 r18732 2012-10-25 |
| 2.5.0beta2 r18947 2012-11-06 |
| 2.5.0beta3 r19070 2012-11-20 |
| | 2.4.6 r19466 2012-10-17
| 2.5.0RC1 r20546 2013-02-04 |
| | 2.4.7 r20857 2013-02-19
| 2.5.0RC2 r20986 2013-02-23 |
|
+-------- branch 2.5 ----------+
| | 2.5.0 r21187 2013-03-04
| | 2.5.1 r22301 2013-04-19
Numeración de la versión: x.y.z
Un nombre de versión siempre se compone de 3 números, si se omite el último, vamos a considerar que es cero: la versión 1.3 es en realidad la versión 1.3.0.
x: el número de versión principal, 1 desde el inicioy: número de versión menor, funciones adicionales (o eliminadas) entre 2 números de versión menorz: número de corrección, 0 cuando es omitida. No hay nuevas características entre 2 números de corrección,'sólo la corrección de errores', las diferencias entre 1.2 y 1.2.1 son realmente menores pero a veces muy importantes (corrección de error de seguridad implícita versión 1.2.1)
Trabajo en paralelo
La principal ventaja del versionado de ramas es que el equipo de desarrollo de Piwigo puede crear nuevas versiones para realizar correcciones en ramas antiguas incluso aunque haya otras nuevas ramas disponibles. Por ejemplo, en caso de que se encontraran errores en la versión 1.3.2, el equipo de desarrollo de Piwigo sin duda corregirá los errores de la versión llamada 1.3.3 aunque la versión 1.4.0 se hubiera lanzado meses después.
Hay dos tipos de ramificaciones en el modelo de desarrollo de Piwigo: ramas estables y una rama para el desarrollo. La rama para el desarrollo se denomina “tronco” (trunk). A partir del tronco, creamos ramas estables como las ramas 1.3, 1.4 o la 2.0.
Para que sea más sencillo para los programadores, el tronco toma un nombre en clave específico cada vez que se crea una rama estable. Ejemplos:
- El tronco (trunk) recibe el nombre en clave de “Alligator” una vez creada la rama estable 1.6. “Alligator” se convirtió en la rama 1.7
- El tronco (trunk) recibe el nombre en clave de “Butterfly”, una vez creada la rama estable 1.7. “Butterfly” se convirtió en la rama 2.0
- El tronco (trunk) recibe el nombre en clave “Colibri” una vez creada la rama estable 2.0. “Colibri” se convertirá en la rama ?.?
Las ventajas de utilizar un nombre en clave para el tronco en lugar del nombre de la rama futura son:
- No siempre sabemos de antemano cuál será el nombre de la futura rama estable (durante varios meses, no sabíamos que “Butterfly” se convertiría en la rama 2.0)
- Respetamos los nombres de rama reales en Subversión
Beta, Versión Candidata, Final
Cuando se prepara una versión, tiene que ser probada y calificada. El equipo de desarrollo de Piwigo funciona de la siguiente forma:
- La versión x.y.zbeta es la versión inicial. Esta versión está diseñada para que la prueben los usuarios más impacientes. Obviamente está dirigida al equipo de desarrollo puesto que puede contener varios errores. Su objetivo consiste en listar todos los errores encontrados para preparar la versión candidata…
- Versión x.y.zRCn (n va desde el 1 hasta… no se sabe hasta qué punto se puede llegar…). Una vez que muchos errores se han corregido de la lista realizada en la versión x.y.zbeta, equipo de desarrollo propone una la Versión Candidata 1. Los que la prueban elaboran la lista de los errores encontrados para que en breve el equipo de desarrollo proponga la RC2. Y así sucesivamente.
- Versión x.y.z (la final) debe ser exactamente la misma que la anterior Versión Candidata, sin ningún error conocido.
Ejemplo: 1.3.0beta » 1.3.0RC1 » 1.3.0RC2 » 1.3.0