Ir al contenido



Foto

Versionado Progresivo o PROGVER: una nueva forma de llevar control de cambios

semver calver romantic versioning sentimental versioning versioning

  • Por favor identifícate para responder
4 respuestas en este tema

#1 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.137 mensajes
  • LocationArgentina

Escrito 09 julio 2018 - 07:40

Muy buenas noches a todos,

Hoy no vengo con preguntas filosóficas de programación. En su lugar vengo con algo diferente. Los invito a un juego: leer y compartir sus visiones, dudas, etc. sobre algo en lo que vengo trabajando desde hace un tiempo.

 

Hace ya unos meses que estudio sobre Git, control de versiones, y los diferentes sistemas de versionado. Y sobre esto último me he sentido "intranquilo" porque cuanto más leía, más llegaba a la conclusión de que hay cuestiones técnicas que no están resueltas.

Quizá para muchos esto les resulte algo secundario, menor, y hasta irrelevante; pero a mi me parece que es mejor darle algo de atención.

 

Quizá la forma más tradicional y difundida de numeración o versionado es la tercia X.Y.Z, y uno de los fomentadores y exponentes más destados de su uso es SemVer, o Versionado Semántico. Pero, ¿sabían que no todo el mundo está utilizando este versionado como corresponde? Hay otros modelos que también tienen una tercia X.Y.Z pero cuyo significado es distinto, ¡Y no se dan cuenta!

Asi que investigué, y efectivamente. Semver no era precisamente lo que estaba buscando. Me encontré con otras propuestas, y tampoco era lo que buscaba.

 

Asi que me dije, ¿Porqué no hago mi propuesta? Asi que empecé. Hace 3 semanas borrador tras borrador, fui poniendo y quitando cosas hasta que di con un método que parece complicado al comienzo, pero es bastante simple en escencia. Como todo papá primerizo uno está super contento con el hijito y lo quiere mostrar al mundo.

 

Les dejo mi propuesta, que aún es prototipo, pero que al menos ya se lo puede considerar funcional.

 

Sepan disculpar que el documento sea largo, pero he buscado ser lo más descriptivo para que se entienda hasta la última gota. Aquí sólo me limitaré a dar una visión muy superficial. Para más información, está el PDF.

 

En PROGVER las versiones siguen la nomeclatura:

 

ProgVer = [<caltype><calversion>]v<Release>.<revision>[-<state>[<numeration>]]{.<breaking>.<feature>.<path>}[+<compilerversion>][@<branchdeploy>]

 

¿Complicado no? Pero véase que la mayor parte es opcional.

PROGVER permite definir un sistema de versión basado en calendario si se desea, y seguidamente fija como dos primeros números de versión release y revision.

Revision no puede modificarse manualmente, más bien es un contador de los cambios que se producen en los niveles inferiores: breaking, feature y/o path. Es decir que cada vez que cambie alguno de estos tres, revision lo hace también.

Tanto release como revision son de carácter público.

 

¿Carácter público? ¿Que es eso? Pues simple, PROGVER permite definir que nivel y profundidad de detalle de versionado dar a conocer públicamente. Por defecto sólo release y revision lo son. E internamente de forma privada se tiene los 3 niveles citados anteriormente. Uno si desea puede desplazar desde breaking hasta path a la parte pública.

 

Seguidamente PROGVER ofrece como metadatos asignarle un estado a nuestro software: alpha, beta, etc. Y si se necesita brindar información específica de alguna compilación está la sección de compilerversion en la que lista las compilaciones e instantáneas que vayamos generando.

Por último es posible añadir información extra como la rama sobre la que estamos extrayendo el software, bittnesss, SO, y cualquier otra cosa que veamos necesaria.

 

La propuesta de PROGVER es que cada versión, cada cambio que realicemos se traduce en un salto de versión y/o de estado. Ya sea explícitamente (dandolo a publicar como una compilación más) o implícitamente (de forma interna, privada) todo es un salto. Y existe un algoritmo que nos va guiando en como desencadenar la numeración. Esto hace que por diseño ¡nuestras versiones estén siempre numeradas y ordenadas de forma automática!

 

Si te interesa ser participante, lo quieres poner a prueba, y/o contribuir a su difusión y a mejorarlo y ampliarlo ven aquí y súmate. Me gustaría recibir algún feedback.

 

Este sistema lo empezaré a utilizar en mis desarrollos prontamente. Pero para enriquecer y probar su efectividad se necesita de más casos de estudios a fin de eliminar el sesgo.

 

Archivo adjunto  VERSIONADO PROGRESIVO.pdf   885,73KB   8 descargas

 

HISTORAL DE CAMBIOS

 

2018-10-09 – v0.2.0.2: Revisión menor
[*]: Formato erróneo en carátula.
[*]: Mal etiquetada la etiqueta <release> cuando debe ser <Release>, con mayúscula.
[*]: Errores ortográficos varios.
[*]: Aclaración de posibles cambios por debajo del nivel de <path>.
[*]: Error de fuente en algunas etiquetas.
[+]: Aclaraciones varias.
[+]: Nueva regla en sistema de calendario, que establece en valor por omisión para <calextension>.

2018-07-09 - v0.1.0.1: Versión inicial del documento

 

Saludos,


  • 2

#2 ELKurgan

ELKurgan

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 523 mensajes
  • LocationEspaña

Escrito 09 julio 2018 - 11:30

Muy interesante el tema...

 

Veré si saco un rato y me pongo a probar

 

Gracias por compartir tu trabajo

 

Saludos


  • 0

#3 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 13.792 mensajes
  • LocationMéxico

Escrito 10 julio 2018 - 09:51

Caramba!!!

Tiene muy buena pinta el documento, felicidades amigo Marchello, las primeras páginas (que he leído) me han gustado, le dí una hojeada rápida y me parece muy interesante el tema.

 

De hecho es un asunto que debería de tomarse en serio.

 

Saludos (y)

 

PD. Ya veremos como promoverlo. :)


  • 0

#4 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.137 mensajes
  • LocationArgentina

Escrito 10 julio 2018 - 05:22

Anoche después de subir el archivo volví a leer el documento. Encontré algunos errores, menores por suerte, por lo que en cuanto pueda los corrijo y subiré una nueva versión. Que como es de esperarse se utilizará ProgVer para si mismo.

 

Saludos,


  • 1

#5 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.137 mensajes
  • LocationArgentina

Escrito 10 julio 2018 - 08:51

Se ha añadido al primer post el historial de cambios. Se adjunta la versión v0.2.0.2 correspondiente en este post.

 

Hay un error que resulta no menor, y debe ponerse en análisis. Resulta que el formato tiene un posible fallo cuando se establezca un calendario Roadmap.

ProgVer establece que en estos escenarios el valor de <Release> es prefijado para el hito. Técnicamente esto implica que en cada uno el valor de <Release> debe de avanzar. La cuestión es que de seguir el diseño como está actualmente podríamos (y deberíamos) llegar en un contexto de liberación semanal programada a un máximo de v52.0. Cuando es posible que en términos más prácticos todas estas versiones sean en realidad una "Subliberación". Esto me hace pensar que quizá no estaría mal añadir un segmento entre <Release> y <revision> llamado <Subrelease>. Las reglas y el mecanismo de los saltos debería de revisarse.

Bajo el mismo sistema de Roadmap, el fallo también impediría que pueda definirse como versión hito que la distribución sea catalogada con el metadato <state>. Considero que en algunas situaciones puede ser útil. Esto necesito comprobarse.

 

Como podrán observar del historial, estos dos errores, no han sido todavía subsanados todavía. Necesito de más tiempo para analizarlo.

 

 

Archivo adjunto  VERSIONADO PROGRESIVOv0.2.0.2.pdf   889,09KB   2 descargas

 

Saludos,


  • 2