Versiones independiente de proyectos en la curricula

[unjust]

Problema: Necesitamos saber cual version de proyecto un cohort esta usando, y ver los cambios (changelog por ejemplo) asociado con este version. Ahora tenemos versionado los releases de curricula como entero y agregamos eso al package.json - pero necesitamos una manera para versionar independiente los proyectos.

Nuestra tipo de proyecto es como un monorepo y necesitamos una manera para trabajar con los proyectos y topicos que existen dentro y tener versiones independientes. Por ejemplo Un proyecto puede seguir siendo el mismo para varios releases, mientras otros proyectos si cambian mucho.

Usamos semver, y quiza necesitamos requerir que cada PR toca la version de de package.json de proyecto.

Algunas preguntas para conversar:

• Hacemos esto manualmente o en un script?
• Tenemos un check en github actions para garantizar eso?
• Adoptamos una herramienta mas especifica y robusto?

[unjust]

Hablando con ChatGPT no tiene nada nuevo. Quiza no estoy haciendo buen prompts. Alguien tiene recursos de diferente formas a hacer eso?

De ChatGPT:

Cuando se gestiona un repositorio que contiene múltiples proyectos, existen varios enfoques comunes para la versionar el software:

Versionar cada proyecto por separado: Tratar cada proyecto dentro del repositorio como una entidad independiente y versionarlos por separado. Esto significa que cada proyecto tendrá su propio esquema de versiones, como el uso de versiones semánticas (por ejemplo, 1.0.0, 1.1.0, 2.0.0) u otro esquema de versionado que se ajuste a tus necesidades. Este enfoque permite flexibilidad al gestionar las versiones y actualizaciones de cada proyecto.

Versionar el repositorio en su conjunto: En lugar de versionar cada proyecto de forma independiente, puedes optar por versionar el repositorio en su totalidad. En este enfoque, se define una versión para el repositorio y se aplica a todos los proyectos que contiene. Esto puede ser útil cuando los proyectos están estrechamente acoplados o interdependientes. Puedes utilizar un esquema de versionado similar al mencionado anteriormente para hacer un seguimiento del progreso general y los cambios en el repositorio.

Combinación de ambos enfoques: También es posible utilizar una combinación de los enfoques anteriores. Puedes tener una versión individual para cada proyecto dentro del repositorio y también mantener una versión para el repositorio en su conjunto. Esto te permite hacer un seguimiento del progreso de los proyectos individuales al mismo tiempo que consideras el estado colectivo del repositorio.

Independientemente del enfoque que elijas, es importante comunicar claramente el esquema de versionado y las convenciones a los miembros del equipo y las partes interesadas. Esto asegura que todos comprendan cómo funciona el versionado y puedan realizar un seguimiento efectivo de los cambios y lanzamientos dentro del repositorio. Además, utilizar etiquetas o lanzamientos en tu sistema de control de versiones (por ejemplo, etiquetas de Git) puede ayudar a marcar hitos o versiones significativas para su fácil referencia y recuperación.

Creo la combinación es lo que queremos. Un version de bootcamp y versiones de proyectos.

• Los versiones de proyectos puede aparecer solo en el package.json de proyecto
• Usamos el formato semver y con criterios como - si solo es tipos o bug seria version patch, si es adiciones de guias o versiones serian minor, y si cambiamos en breaking change (no se, el stack, la tema, nuevos requisitos?) seria version major Tenemos que hablar de esos criteros
• Hacimos manualmente, o no se como hacerlo automaticamente (quiza usando los mensajes de commit y un github action?)

https://chat.openai.com/share/2f7c5c0c-2307-4ef7-ae3d-0e9cb244a717

[mfdebian]

@merunga @lupomontero ¿Tienen algún tip o guía que nos puedan dar para que solucionemos este issue? Creo que nos toca conversar cuál es la estrategia a tomar para satisfacerlo.

[unjust]

Muy crudo voy a explicar una idea de un proceso que podemos adaptar.

No creo podemos automatizar la tarea de versionar a 100% - pero podemos agregar algunos checks para recordar que este ocurre, que cada vez un archivo de un proyecto cambia, la version en el package.json esta actualizado (hay un commit que toca package.json y con mensaje de chore y version por ejemplo)

Podemos implementar un github action que busca si un archivo esta cambiado dentro projects/ asegura que hay un commit mensaje que habla de bump version. No se si podemos ser mas precisa (determina cual proyecto fue cambiado y analizar los commits de su pakage.json en particular)

Algunas github actions que podemos adoptar para verificar un bump de release: https://github.com/marketplace/actions/gs-commit-message-checker https://github.com/marketplace/actions/git-semantic-version https://github.com/marketplace/actions/git-semantic-version#using-multiple-versions-in-the-same-repository

[merunga]

No se si entiendo todo el flujo, pero exploraría los flujos propuestos por turborepo

[unjust]

Revise otras opciones:

• https://github.com/semantic-release/semantic-release/tree/master - no creo este funciona con monorepos
• https://github.com/changesets/changesets/blob/main/docs/adding-a-changeset.md - funciona facil con monorepos, pero me parece que estoy haciendo un commit extra con cada changeset, y de ahi otro commit para actualizar el version. no se si collaboradores van a entender el flujo
• https://github.com/intuit/auto - no se como funciona con monorepos

[unjust]

Otra manera un poco mas estructurado y robusto que solo tener algo de revisar los mensajes de commits. La idea es explicado mas o menos en este articulo

1. Enforzamos los commit messages para tener la estructura https://www.conventionalcommits.org/en/v1.0.0/#specification
2. usamos un herramienta para analizar los mensajes como release-please de google que dice funciona con mono repos Un ejemplo con monorepo

Mas de release please: https://danwakeem.medium.com/improve-your-github-releases-10x-with-this-one-simple-action-56e59e46dd85

[unjust]

@mfdebian quedamos con la decision a no adoptar herramientas como changeset/turbo pero tener como convencion un commit en cada pull request de proyecto que describe que esta haciendo un version bump. Y usamos un gh action para buscar este formato y levantar un error si no parece un commit que describe el cambio de version.

Hay que comunicar este convencion con el equipo y en Contributing.md

[mfdebian]

Luego de darle harta reflexión, dejo mis 2 cents:

Está bien que cada proyecto, al ser creado por una coach para que lo usen las estudiantes, contenga en su package.json el atributo version igual a 1.0.0 (o inclusive 0.1.0) dado que luego las estudiantes al hacer fork, decidirán cómo utilizar semánticamente ese versionado, pero también entiendo la necesidad de poder identificar de manera fácil si un proyecto efectivamente ha tenido cambios, y sobretodo, utilizando semver, saber qué tipo de cambios ha tenido, entonces creo que no es ese el atributo que deberíamos estar utilizando para esto.

Creo que lo más natural, sería agregar al objeto bootcamp que se genera dentro de los package.json al ejecutar el script create-cohort-project un atributo tipo project-version y que ahí esté esa versión que internamente sabremos cómo manejar.

Cabe entonces preguntarse de dónde vendría ese dato, mi primera intuición fue pensar que viniera inmediatamente de los package.json de los proyectos que se encuentran dentro del directorio projects/ del repo, sin embargo, no todos los proyectos tienen package.json y es más, habrán algunos, como notes, donde las estudiantes ejecutarán un comando para crear una app de React que tendrá su propio package.json con los scripts, etc... e incluso, qué pasaría con los proyectos de UX que probablemente no contemplen durante todo su desarrollo el tener este archivo.

Lo que propondría, es que esa metadata de la versión del proyecto, provenga del archivo project.yml que todos los proyectos tienen, incluyendo los de UX, y podríamos agregarle un atributo version o project-version que luego el script create-cohort-project pueda leer y agregar el objeto bootcamp en los package.json donde sea pertinente, y además que el curriculum-parser pueda saber para agregalo al objeto project que luego vemos en los archivos que se encuentran dentro del directorio dist/ cómo la ven? les hace sentido lo que comento?

[unjust]

@mfdebian actualize la descripcion mejor con el problema: "Necesitamos saber cual version de proyecto un cohort esta usando, y ver los cambios (changelog por ejemplo) asociado con este version."

Seria bueno si cada proyecto que sale en "create cohort project" tiene algun manera saber de su ultima version - un version, tag o SHA - y que fue los cambios con este version major/minor o patch.

Hice un experimento rapido con release-please y me gusta mucho los resultados - como genera una nueva version con el changelog. Posiblemente podemos cambiar donde hace el bump, pero despues pensando y usandolo creo tiene sentido usar el version en package.json para tener este información. (Pero quizas podemos configurar eso o hacer un paso con create-cohort-project.)

El experimento fue muy facil.

1. Instale el CLI de release-please en mi sistema
2. Hice una rama next en mi repo, como planeamos tener en curricula - no es obligatorio, pero me ayudo simular el flujo mejor
3. Hay que "bootstrap" el repo con release-please , creando dos .json
   • release-please-config.json donde defines los packages que quieres trackear, el tipo de package es node por defecto, entonces release-please sabe augmentar la version en package.json. Podemos agregar o omitir cualquier proyecto aqui, entonces si no tiene package.json no tenemos que trackearlos.
   • un manifest que al principio hice con un objeto {}, pero despues release-please actualiza automaticamente
4. hice dos PRs que hacen cambios a proyectos distintos.
   • https://github.com/unjust/bootcamp/pull/13 un feat
   • https://github.com/unjust/bootcamp/pull/12 con un fix
   • Hay que asegurar que un commit en el merge o el commit de squash/rebase tiene la sintaxis fix: feat: y con ! que significa breaking change. Usaba la sintaxis de conventional commits que es muy lijera.
5. Despues mergear los PRs en next, para "preparar" un release corrí el commando release-please --token=MY_TOKEN --repo-url=unjust/bootcamp --target-branch=next release-pr que genera un pull request con los versiones actualizado y changelogs. Podemos mergear este pull request a next antes de hacer un release en main, para tener changelogs y versiones correctos.

Hay mas configuraciones que podemos explorar/customizar pero con eso creo el flujo fue rapido y suficiente para nuestras necesidades.

[unjust]

@mfdebian para mi ahora (perdon que cambie mi idea), tiene sentido que actualizamos la version de proyecto usando la version en package.json. Si no estamos en acuerdo con eso, quiza el create-cohort-script puede tomar la version de proyecto, agregarlo al propiedad "bootcamp" en el json , y actualizar el version de proyecto individual a 1.0.

Tambien, podemos explorar como hacer versiones con topicos (no se si release-please apoya versiones de proyectos con front-matter).

[mfdebian]

@unjust revisé lo que me compartiste, encontré bacán que sólo con identificar si el commit contiene la palabra fix o feat te ayude a modificar el número de versión del package.json pero entiendo que al final, lo que llama release en este caso sería hacer ese PR con los cambios en los package.json no? o al integrar ese PR efectivamente genera un release en github?

en cualquier caso, sería modificado el atributo version del package.json de cada proyecto, y en mi opinión ese no debería ser el atributo que deberíamos estar modificando, ya que cada estudiante debería partir su fork con una versión 1.0 (o 0.1 incluso), pero tampoco quiero ser una piedra en el camino para esto, busquemos más opiniones! a ver si alguien más tiene alguna opinión que nos pueda aportar! :pray:

[unjust]

@unjust revisé lo que me compartiste, encontré bacán que sólo con identificar si el commit contiene la palabra fix o feat te ayude a modificar el número de versión del package.json pero entiendo que al final, lo que llama release en este caso sería hacer ese PR con los cambios en los package.json no? o al integrar ese PR efectivamente genera un release en github?

Este es solo para crear un PR con las actualizaciones de version. El PR que genera con los versiones actualizado podemos mergear a next pero eso no es un release tal cual y de ahi podemos hacer nuestro proceso de release, actualiza deps, mergear y etiquetar al main. Hay un comando en el CLI que podemos tambien hacer un release, pero no he investigado, solo use el release-pr funcionalidad. https://github.com/googleapis/release-please/blob/main/docs/cli.md#creating-a-release-on-github

en cualquier caso, sería modificado el atributo version del package.json de cada proyecto, y en mi opinión ese no debería ser el atributo que deberíamos estar modificando, ya que cada estudiante debería partir su fork con una versión 1.0 (o 0.1 incluso), pero tampoco quiero ser una piedra en el camino para esto, busquemos más opiniones! a ver si alguien más tiene alguna opinión que nos pueda aportar! 🙏

Apoyo el cambio de version pero tambien podemos hacer que al momento de create-cohort-project movimos/copiamos la version de proyecto al parte de bootcamp en el package.json re-inicializa la version a 1.0

[unjust]

Cosas para comprobar

• como es el comportamiento de proyectos "simple" como ux o que no tiene package.json
• como seria las versiones iniciales en el manifest (ej todos 1.0.0 o algunos en 2.0.0 ?)
• si podemos configurar o no escribir un changelog en los packages / proyectos
• cambios a create-cohort-project para escribir el version y reset el version a 1.0.0