@@ -85,13 +85,13 @@ Adicionalmente están las ramas *release*, que por lo regular tendrán una tarea
...
@@ -85,13 +85,13 @@ Adicionalmente están las ramas *release*, que por lo regular tendrán una tarea
A continuación se presenta una guía del flujo de una rama tipo *feature*. Aquí se consideran tanto los pasos y recomendaciones para el encargado de hacer la tarea, como para los revisores.
A continuación se presenta una guía del flujo de una rama tipo *feature*. Aquí se consideran tanto los pasos y recomendaciones para el encargado de hacer la tarea, como para los revisores.
[^1]
#### Rama *Release*
#### Rama *Release*
A continuación se presenta una guía del flujo de una rama tipo *release*. Aquí se consideran tanto los pasos y recomendaciones para el encargado de hacer el lanzamiento, como para los revisores.
A continuación se presenta una guía del flujo de una rama tipo *release*. Aquí se consideran tanto los pasos y recomendaciones para el encargado de hacer el lanzamiento, como para los revisores.
[^2]
#### Rama *Hotfix*
#### Rama *Hotfix*
...
@@ -99,7 +99,7 @@ Las tareas de estas ramas son para corregir algo urgente que no da tiempo de esp
...
@@ -99,7 +99,7 @@ Las tareas de estas ramas son para corregir algo urgente que no da tiempo de esp
A continuación se presenta una guía del flujo de una rama tipo *hotfix*. Aquí se consideran tanto los pasos y recomendaciones para el encargado de hacer el ajuste, como para los revisores.
A continuación se presenta una guía del flujo de una rama tipo *hotfix*. Aquí se consideran tanto los pasos y recomendaciones para el encargado de hacer el ajuste, como para los revisores.
[^3]
### Lanzamientos y etiquetas (Releases, tags)
### Lanzamientos y etiquetas (Releases, tags)
...
@@ -112,12 +112,6 @@ Al crear un lanzamiento, se debe tener en cuenta lo siguiente:
...
@@ -112,12 +112,6 @@ Al crear un lanzamiento, se debe tener en cuenta lo siguiente:
1. No especificar cada commit ni cada tarea, solo los cambios en funcionalidades completas.
1. No especificar cada commit ni cada tarea, solo los cambios en funcionalidades completas.
2. No detallar cambios técnicos. Por ejemplo, solo “*dependency update*” en lugar de listar todas las dependencias que se cambiaron
2. No detallar cambios técnicos. Por ejemplo, solo “*dependency update*” en lugar de listar todas las dependencias que se cambiaron
[^1]:[Editable para el diagrama de las ramas feature](https://drive.google.com/drive/folders/12YStpH9Y7vrZcBHs8i9sfnPyG7LlWI7l)
[^2]:[Editable para el diagrama de las ramas release](https://drive.google.com/drive/folders/12YStpH9Y7vrZcBHs8i9sfnPyG7LlWI7l)
[^3]:[Editable para el diagrama de las ramas release](https://drive.google.com/drive/folders/12YStpH9Y7vrZcBHs8i9sfnPyG7LlWI7l)
[^volver]:volver al [inicio](/README.md)
---
---
* volver al [inicio](/README.md)
* volver al [inicio](/README.md)
* volver a las [normas de desarrollo](/docs/development-rules/README.md)
* volver a las [normas de desarrollo](/docs/development-rules/README.md)
@@ -11,7 +11,7 @@ Para el versionamiento de proyectos de software, seguimos las especificaciones d
...
@@ -11,7 +11,7 @@ Para el versionamiento de proyectos de software, seguimos las especificaciones d
* En el formato **X.Y.Z**:
* En el formato **X.Y.Z**:
* El número **X** indicará un número de versión mayor, corresponde a cambios que no tienen compatibilidad con versiones anteriores (por ejemplo, un cambio completo de una API)
* El número **X** indicará un número de versión mayor, corresponde a cambios que no tienen compatibilidad con versiones anteriores (por ejemplo, un cambio completo de una API)
* El número **Y** indicará un número de versión menor, indica cambios compatible con versiones anteriores (por ejemplo, nuevas características o ajustes de bugs no prioritarios)
* El número **Y** indicará un número de versión menor, indica cambios compatible con versiones anteriores (por ejemplo, nuevas características o ajustes de bugs no prioritarios)
* El número **Z** indicará un número de parche, lo que se denomita un `hotfix` en inglés.
* El número **Z** indicará un número de parche, lo que se denomina un `hotfix` en inglés.
* Nunca se deberá modificar el contenido de una versión existente. En caso necesario se debe crear una nueva versión.
* Nunca se deberá modificar el contenido de una versión existente. En caso necesario se debe crear una nueva versión.
* Al realizar un lanzamiento nuevo en *GitHub* (*[Release](https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases)*), el título deberá ser el número del lanzamiento (por ejemplo, *1.2.0*)
* Al realizar un lanzamiento nuevo en *GitHub* (*[Release](https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases)*), el título deberá ser el número del lanzamiento (por ejemplo, *1.2.0*)
* Todo lanzamiento de una nueva versión deberá tener una descripción detallada de los cambios en la misma.
* Todo lanzamiento de una nueva versión deberá tener una descripción detallada de los cambios en la misma.
El uso de diferentes herramientas y frameworks será determinado para cada proyecto, en conjunto con los miembros del equipo, a continuación se presentan algunas recomendaciones generales.
El uso de diferentes herramientas y frameworks será determinado para cada proyecto, en conjunto con los miembros del equipo, a continuación se presentan algunas recomendaciones generales.
### Recomendaciones generales
* Tener compatibilidad total con el sistema operativo *GNU/Linux* (para facilitar su contenerización y orquestación).
## Back end
## Back end
Un proyecto de back end debe:
Un proyecto de back end debe:
* Tener compatibilidad total con el sistema operativo *GNU/Linux* (para facilitar su contenerización y orquestación).
* Utilizar transacciones en servicios que almacenen datos en 2 o más tablas de una base de datos *SQL* de manera simultánea.
* Utilizar transacciones en servicios que almacenen datos en 2 o más tablas de una base de datos *SQL* de manera simultánea.
