search

EthicApp-Development / ethicapp-main

EthicApp's main repository containing backend and frontend applications
MIT License
1 stars 1 forks source link

Establecer mecanismo de releases #94

Closed ifgarces closed 1 year ago

ifgarces commented 1 year ago

Descripción general

¿Cuándo se usaría?

Al publicar y desplegar una nueva versión de EthicApp (de acuerdo al versionamiento).

Más información

Requiere muy buen conocimiento de la documentación existente y del historial de cambios con respecto a la versión 1.0.

ifgarces commented 1 year ago

Junto con @mabarraza hemos acordado:

Se adoptará un estándar de nombre de versionamiento SemVer, donde el MINOR será el nivel de granularidad, es decir, cada release, a partir del lanzamiento de EthicApp 2.0, será nombrado de la forma:

MAJOR_VERSION.MINOR_VERSION

Cada merge hacia la branch principal (master) deberá tener cambios estables y suficientes como para formar una nueva MINOR_VERSION. Al hacer esto (usando los releases propios de GitHub), deberá ser acompañado de release notes con el siguiente formato:

MAJOR.MINOR

Novedades principales

[Lista de cambios visibles muy orientados al usuario no técnico, e.g. académicos]

Aspectos técnicos

[Lista más granular con cambios técnicos relevantes, e.g. los issues relevantes resueltos]

ifgarces commented 1 year ago

En el caso de un hotfix (solución de un bug importante de forma urgente) para una versión, se deberá lanzar un nuevo release pero esta vez con formato de nombre:

MAJOR_VERSION.MINOR_VERSION.PATCH

Donde las release notes detallen el cambio.

Nota: el lanzamiento de EthicApp 2.0 seguirá el mismo formato de release notes.

ifgarces commented 1 year ago

Cerrado en https://github.com/EthicApp-Development/organization/commit/9e82278be3af5a27fed3a78e67712af5e9dff3a6 (agregado a la documentación del proyecto)

claudio-alvarez commented 1 year ago

En release notes debiera existir un apartado que describa known issues.

claudio-alvarez commented 1 year ago

Por otro lado, ¿por qué no estamos considerando un CHANGELOG?

ifgarces commented 1 year ago

Por otro lado, ¿por qué no estamos considerando un CHANGELOG?

Técnicamente incluiríamos ambos, la sección "Aspectos técnicos" (tal vez no con el mejor nombre) de las release notes serían realmente el changelog del release, es decir, más detallado y técnico. La sección "Novedades principales" serían orientadas a usuarios comunes. Si te refieres a tener un changelog global (un archivo grande con los cambios históricos), en mi opinión es arcaico y carece de sentido gracias a los releases de GitHub donde se tiene un historial claro.

ifgarces commented 1 year ago

En release notes debiera existir un apartado que describa known issues.

Sí, creo que es buena idea, lo voy a agregarlo a la documentación

ifgarces commented 1 year ago

Por otro lado, ¿por qué no estamos considerando un CHANGELOG?

Técnicamente incluiríamos ambos, la sección "Aspectos técnicos" (tal vez no con el mejor nombre) de las release notes serían realmente el changelog del release, es decir, más detallado y técnico. La sección "Novedades principales" serían orientadas a usuarios comunes. Si te refieres a tener un changelog global (un archivo grande con los cambios históricos), en mi opinión es arcaico y carece de sentido gracias a los releases de GitHub donde se tiene un historial claro.

Nota: nos basamos en el formato general de Releases de, por ejemplo, ScrCpy donde se tiene el changelog y los highlights orientados al usuario común. ¿Tal vez deberíamos renombrar las secciones de las release notes definidas?

claudio-alvarez commented 1 year ago

Por otro lado, ¿por qué no estamos considerando un CHANGELOG?

Técnicamente incluiríamos ambos, la sección "Aspectos técnicos" (tal vez no con el mejor nombre) de las release notes serían realmente el changelog del release, es decir, más detallado y técnico. La sección "Novedades principales" serían orientadas a usuarios comunes. Si te refieres a tener un changelog global (un archivo grande con los cambios históricos), en mi opinión es arcaico y carece de sentido gracias a los releases de GitHub donde se tiene un historial claro.

Ok, me parece bien usar el historial automático de releases en GitHub, sin embargo, estaba viendo que esto es altamente configurable (archivo .github/release.yml). ¿Hay elementos configurables pertinentes de acuerdo a lo discutido por @mabarraza y por ti?

https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes

ifgarces commented 1 year ago

No sabía que existía esa opción para automatizar release notes, está genial, voy a revisarlo. Por mientras, decidí renombrar "Aspectos técnicos" a "Changelog" y agregué la sección "known issues". Ver Git workflow.md

mabarraza commented 1 year ago

No llegamos a discutir respecto a ese punto, lo revisaré

claudio-alvarez commented 1 year ago

No sabía que existía esa opción para automatizar release notes, está genial, voy a revisarlo. Por mientras, decidí renombrar "Aspectos técnicos" a "Changelog" y agregué la sección "known issues". Ver Git workflow.md

Gracias @ifgarces y @mabarraza, creo que estamos logrando abarcar varios aspectos importantes del proceso de releases. Algo que me llama la atención es que el software en sí, esto es, descontando lo que ocurre en el repositorio, no tiene ninguna información de versiones (¿o sí? - esto siendo que release notes en principio sería administrado por GitHub y no incorpora modificaciones al código ni agrega archivos automáticamente). Por ejemplo, si pongo a ejecutar en producción una determinada versión de EthicApp, la única forma de conocer el número de versión que se está ejecutando es ponerme a mirar el historial de git en la copia local instalada en producción, y mirar el hash que tiene, a menos que el formato de commit incorpore también la información relativa a la versión.

A su juicio, ¿qué forma sería más apropiada para incorporar el número de versión al software mismo y que esto vaya en sincronía con lo que pasa en el repositorio?

ifgarces commented 1 year ago

Ok por lo que entendemos con @mabarraza hablas sobre que en el código fuente se pueda saber en qué versión se está.

Teniendo en cuenta el tamaño actual del proyecto y su naturaleza académica, automatizar el proceso del versionamiento al nivel de software (interno) es complejo a priori y tampoco es prioritario ahora mismo. Es posible que se desee dentro del roadmap de EthicApp 3.0 en adelante, cuando el proyecto open-source vaya madurando, que se automatize mediante algún comando de git, obtener en el código (JS) el nombre de la versión que está ejecutando (para que se entienda, una función getCurrentReleaseName()). Pero por ahora, si de verdad fuera necesario (ahora mismo no creemos) obtener el nombre de la versión actual en código fuente, se optará por dejar el nombre de la versión actual (e.g. MAJOR.MINOR) como constante en el Javascript, que deba actualizarse manualmente en cada release (e.g. una global const CURRENT_RELEASE_NAME).

ifgarces commented 1 year ago

En teoría debería estar cerrado el issue porque se definió el estándar y la metodología y solo falta abordar las issues asociadas #110 y #111.