@@ -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.
[^1]
#### 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.
[^2]
#### Rama *Hotfix*
...
...
@@ -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.
[^3]
### Lanzamientos y etiquetas (Releases, tags)
...
...
@@ -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.
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 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
* 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 **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.
* 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.
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
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.
