# LMS Git Conventions - Setup

## Current status

- Versión: `v0.1.7`
- Entornos: 
  * [`Producción`](https://lms.laboratoria.la)
  * [`Staging`](http://laboratoria-la-lms-staging.firebaseapp.com)
  * [`Experimentación`](https://laboratoria-pblms.firebaseapp.com/)
- Planificación 
  * Versión `0.2.0` está planificado para el feature de experimentación que se está trabajando (Project based LMS).
  * Versión `0.1.8` sería el siguiente release de la versión que está en producción.
  * Cada feature pequeño estamos actualizándolo como si fuera un _patch_.
  * Solo tenemos el branch `master` donde se solicitan todos los PRs que se preparan para el siguiente release.
  * Se tiene un branch de `develop` que es una copia de `master`, pero no contiene ningún feature diferente aun.
  
## Applying our Git conventions

Si seguimos las [convenciones de Git propuestas](https://gist.github.com/ivandevp/41bfb0c77b38d042456dc8fbb4aba885), 
podríamos hacer algunos cambios y tener un flujo como siguiente:

### Versioning

- `v0.1.8`, siguiente bug fix que se encuentre en producción.
- `v0.2.0`, siguiente feature pequeño que no genere un cambio fuerte en el entorno actual.
- `v1.0.0`, siguiente release que implique cambios que rompan las versiones anteriores. Ejemplo, agregar proyectos
  como feature en el LMS y que cambie la estructura de cohorts y cursos. Este debería seguir las etapas del proceso
  de desarrollo.

### Branches

Las ramas que actualmente podríamos tener, serían:

- `master`: Versión de producción.
- `develop`: Desarrollo de features que serán incluidos en el release `v0.2.0`.
- `v1.0.0-dev`: Desarrollo de los features que serán parte del release `v1.0.0-alpha`, básicamente los del 
  *Project Based LMS*.
  
### Pull Requests

Los pull requests cambiarían de acuerdo al feature que se esté desarrollando:

- `master`: Solo se hará pull requests desde la rama `release/v0.x.y` que se cree cuando un set de features se haya
  terminado en la rama `develop`, o  la rama `hotfix/foo` que se haya creado para hacer un fix que necesita corregirse
  sobre la base de producción.
- `develop`: Solo se hará pull requests desde los forks de los devs, estos deberían incluir los features a incluir 
  para la siguiente versión de producción.
- `v1.0.0-dev`: Solo se hará pull requests desde los forks de los devs, estos incluirán features o fixes de lo necesario
  para el desarrollo del *Project Based LMS*.
  
### Releases

- La versión de producción seguirá el flujo de Semver: `MAJOR.MINOR.PATCH`.
- El desarrollo de la versión del *Project Based LMS*, seguirá las etapas de desarrollo, haciendo los pre-releases:
  * `v1.0.0-alpha.X`
  * `v1.0.0-beta.X`
  * `v1.0.0-rc.X`
  
  > Nota: Podemos usar como referencia el [flujo llevado por el equipo de Material UI](https://github.com/mui-org/material-ui/releases).
- El release de esta versión debería quedar en la `v1.0.0` al menos que haya un _major change_ antes de esto.