Mejora 71

[mqelvira]

Prueba de pull request. Se camiba el color de la ventana de registro de entrada para diferenciarlo del registro de salida.

[jormaral]

¿Puedes hacer el P.R contra la rama development? De momento intentemos dejar el Master sin tocar, thanks.

[erny]

Yo he mezclado mi pull request consistente en lote de commits orientados a mejorar la compilación con Java 6 / maven 2.2.x en la rama development.

Para todos los futuros cambios abriré ramas específicas, ya que los pull requests parecen cubrir ramas completas y no se pueden acotar por commits concretos.

[jormaral]

Como mejor lo veas, sin problema.

[erny]

@mqelvira El commit "Se añade la rama" https://github.com/mqelvira/alsigm/commit/159c2477b641491f6b9250a6f63a4221b17afbb1 ¿qué cambia? ¿Son sólo cambios de espacios / saltos de línea ? (1370)

[jormaral]

Supongo será una prueba.

[erny]

@mqelvira En el commit https://github.com/mqelvira/alsigm/commit/d1271ab273322cd38b4486eeacfbc6aeb3485ead aparecen dentro de los comentarios referencias a fecha / autores. Igualmente aparecen nombres de archivos que terminan con ".dipucr". Supongo que eso no es lo que se quiere mezclar en "master", ¿no?

[jormaral]

No, por eso @borillo les comentaba lo de hacer los P.R con "buenas prácticas". Creo que no habría que mezclarlo en el Master de ahí mi sugerencia de utilizar la development. Si crees que debe ser otra rama se utiliza otra, o si hay que crear otra se crea.

[borillo]

Buenas @erny y @jormaral. El modelo del que hablamos es que master sólo reciba merges desde development cuando un conjunto de funcionalidad está ya finalizada y revisada convenientemente.

En este sentido, los PR deberían ser mergeados primero en development y, después de estabilizarse, pasar a master cuando una versión se cierre (acompañado de su correspondiente TAG y maven:release al tratarse de una nueva versión).

Respecto a development, la propuesta era que para para cada funcionalidad nueva se abriera una rama desde la propia rama de development (feature branching). De esta manera se podría trabajar de forma aislada y sin romper nada en development y controlar los cambios de lo que al final acaba mezclándose en development, así como el PR final que sería contribuido.

¿Es lo que llevabais en mente?

[jormaral]

Muchas gracias Ricardo, exactamente es eso explicado con más detalle. Por mi parte estoy totalmente de acuerdo con lo que propones, me parece un procedimiento ejemplar.

Gracias.

[erny]

Hola @borillo

Yo ya he empezado. Estoy usando la siguiente nomenclatura para las ramas en mi repo fork.

fix/[issue]_[descriptive_text] para corregir los errores o feature/[descriptive_text] según sea una nueva funcionalidad que cubre varios issues.

Estoy abierto a vuestras sugerencias.

Refs:

• http://stackoverflow.com/questions/273695/git-branch-naming-best-practices
• http://www.guyroutledge.co.uk/blog/git-branch-naming-conventions/ (slash notation)