🌍
Español
Diferencias
Muestra las diferencias entre dos versiones de la página.
|
acerca_de:control_de_versiones [2013/05/20 11:37] albertparera creado |
acerca_de:control_de_versiones [2013/05/20 15:30] (actual) albertparera [Trabajo en paralelo] |
||
|---|---|---|---|
| Línea 1: | Línea 1: | ||
| - | ====== Branches and releases ====== | + | ====== Control de versiones ====== |
| - | How does the Piwigo release system work? What is the difference between the release 1.3.1 and release 1.4.0? | + | ¿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? |
| - | ===== Releases ===== | + | ===== Versiones ===== |
| - | A release is a kind of snapshot of the code at a precise instant. Release 1.3.1 will never be modified, if needed, a release 1.3.2 will appear. The snapshot is taken on a branch therefore release 1.3.1 is a snapshot taken on branch 1.3. A branch evolves through improvement and bug fixing. But a branch does not move considering its features: there will be no additional features in release 1.3.3 than in release 1.3.0, only code improvement, bug fixing and so on. | + | 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 ===== | ||
| - | ===== Branches with a graph ===== | + | Representación jerárquica de ramificaciones y versiones de Piwigo hasta la fecha: |
| - | + | ||
| - | What about an ASCII art graph of branches and releases: | + | |
| +-------+ | +-------+ | ||
| Línea 136: | Línea 136: | ||
| | | 2.5.1 r22301 2013-04-19 | | | 2.5.1 r22301 2013-04-19 | ||
| - | ===== Release numbers : x.y.z ===== | + | ===== Numeración de la versión: x.y.z ===== |
| - | + | ||
| - | A release name is always composed of 3 numbers, if the last one is omitted, let's consider it's zero : release 1.3 is in fact release 1.3.0. | + | |
| - | + | ||
| - | * ''x'' : the major release number, 1 since the beginning and for some time I think | + | |
| - | * ''y'' : minor release number, additional (or removed) features between 2 minor release number | + | |
| - | * ''z'' : correction number, 0 when omited. No new features between 2 correction number, '''only bug correction''', differences between 1.2 and 1.2.1 are really minor but sometimes very important (security bug correction implied release 1.2.1) | + | |
| - | + | ||
| - | ===== Parallel working ===== | + | |
| - | The main advantage of branch versionning is that Piwigo development team can still create new fixing releases on an old branch even if a new branch has been available. For example, if you find some bugs in release 1.3.2, Piwigo development team will certainly fix bugs for a release called 1.3.3 even if release 1.4.0 has already bee out for months. | + | 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. |
| - | There are two kinds of branchs in Piwigo development model : stable branches and a development branch. The development branch is called "trunk". From trunk, we create stable branches such as branch 1.3, 1.4 or 2.0. | + | * ''x'': el número de versión principal, 1 desde el inicio |
| + | * ''y'': número de versión menor, funciones adicionales (o eliminadas) entre 2 números de versión menor | ||
| + | * ''z'': 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 ===== | ||
| - | To make it more simple for developers, the trunk gets a new specific codename each time a stable branch is created. Examples: | + | 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. |
| - | * trunk gets the codename "Alligator" once stable branch 1.6 was created, "Alligator" became branch 1.7 | + | |
| - | * trunk gets the codename "Butterfly" once stable branch 1.7 was created, "Butterfly" became branch 2.0 | + | |
| - | * trunk gets the codename "Colibri" once stable branch 2.0 was created, "Colibri" will become branch ?.? | + | |
| - | The advantages of using a codename on trunk instead of the futur branch name are: | + | 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. |
| - | * we don't always know in advance what will be the name of the future stable branch (during several months, we didn't know "Butterfly" would become branch 2.0) | + | |
| - | * we respect real branch names in Subversion | + | |
| - | ===== Beta, Release Candidate, Final ===== | + | 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 ?.? | ||
| - | When preparing a release, it has to be tested and qualified. Piwigo development team works as follows: | + | 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 ===== | ||
| - | - release x.y.zbeta is first available. This release is designed for test by most impatient users. It is obvious for the dev team that this release may contain many bugs. The purpose is to list them all to prepare the release candidates... | + | Cuando se prepara una versión, tiene que ser probada y calificada. El equipo de desarrollo de Piwigo funciona de la siguiente forma: |
| - | - release x.y.zRCn (n goes from 1 to... you can't know how far it can go...). Once many bugs have been corrected from the list made in release x.y.zbeta, dev team proposes a Release Candidate 1. Testers give the list of found bugs and after a (short) while, dev team proposes RC2. And so on. | + | |
| - | - release x.y.z (the final one) must be exactly the same than the last Release Candidate, without any known bug. | + | |
| - | Example : 1.3.0beta >> 1.3.0RC1 >> 1.3.0RC2 >> 1.3.0 | + | - 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 | ||