5 replies to this topic

[Delphius]

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.

 

 VERSIONADO PROGRESIVO.pdf   885.73KB   13 downloads

 

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,

[ELKurgan]

Muy interesante el tema...

 

Veré si saco un rato y me pongo a probar

 

Gracias por compartir tu trabajo

 

Saludos

[egostar]

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

 

PD. Ya veremos como promoverlo.

[Delphius]

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,

[Delphius]

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.

 

 

 VERSIONADO PROGRESIVOv0.2.0.2.pdf   889.09KB   2 downloads

 

Saludos,

[Delphius]

He estado trabajando en una nueva mejora. Aunque todavía no está lo suficiente madura para ser liberada.

No estoy seguro en cuanto tiempo tendré preparado el documento, pero si puedo comentar que los cambios son significativos. Al punto en que quizá valga la aparición de una liberación 1, y rompe el diseño viejo en muchas partes.

 

Algunas cosillas que puedo mencionar:

• Se añadirá un segmento adicional llamado <subrelease>, que dependiendo del tipo/formato de versionado elegido será opcional u obligatorio. Esto es para evitar que <release> incremente demasiado (e/o innecesariamente) en un versionado basado en calendario.
• Se mantiene el concepto de visibilidad pública, privada, y semipublica pero la forma en como se define el separador entre privado/interno y publico va a cambiar. En lugar de establecer un único separador, ahora admitirá un conjunto de segmentos. Por tanto lo que lo que se defina dentro de éste será considerada numeración interna/privada. El rango se prestablece por defecto según el tipo de versionado elegido.
• Como elemento de visibilidad privada/interna por defecto se considerará <breaking>.<feature>.<path>.
• Se permitirá mover <release> y <subrelease> como privado si se desea (siempre y cuando el tipo/formato lo permita). Esto nos deja solamente a <revision> como único segmento de alcance público en el escenario más restrictivo.
• <revision> sigue siendo de naturaleza un contador. Aunque ahora su "ordenamiento" (y el "significado") está condicionado al tipo/formato de versionado elegido, y a como se configure el versionado privado.
• Se modificará ligeramente el formato del versionado calendario. La intención es que sea más fácil leer y distinguir entre sus dos posibilidades: libre y/o roadmap.
• El mecanismo de salto se rediseñará para aceptar este nuevo segmento y dependerá del tipo/formato de versionado. Además deberá permitir que se defina un salto en un versionado calendario tanto libre como roadmap una liberación que incluya la metadata <-state>. Actualmente en un roadmap no es posible en un hito hacer una liberación de una version con estados. Este error fue detectado como se comentó antes.
• Se formalizará el concepto de tipo/formato de versionado: se deberá definir al comienzo si optará por un diseño calendario (existiendo en sus formas: de liberación libre o una programación basada en hojas de ruta o roadmap), o un versionado numérico. Dependiendo de la elección del tipo/formato se define los elementos obligatorios, los opcionales y el rango publico/privado.

 

En pocas líneas, la elección del tipo/formato implica para el:

* Versionado calendario libre: <release> y <subrelease> son opcionales, y por defecto no son usados. Esto dejará como público por defecto solamente a <revision>. El versionado interno por defecto contendrá <breaking> y menores. Esto hace que visualmente se comporte y semeje a un calver.

* Versionado calendario roadmap: hace obligatorio el uso de <release>, <subrelease> y <revision> e inamovibles al versionado interno. Impone un sistema de salto que condiciona la posibilidad de incrementar tanto <release> como <subrelease> a menos que se defina un tipo especial de salto de validación de un hito alcanzado. Versionado interno: <breaking> y menores.

* Versionado numérico: No hay sistema de calendario. Hace opcional y por defecto no se usa <subrelease>. Esto deja que la visibilidad pública por defecto sea solamente <release> <revision>. Internamente contiene a <breaking> y menores.

 

Quizá se pregunten ¿porqué ahora pueden ser opcionales y/o movibles los segmentos? ¿Cuál es el objetivo de esto? Pues, para dar la mejor flexibilidad. Y más importante aún, para poder ajustarse adecuadamente al sentido esperado cuando uno define un sistema de versionado.

 

En un sistema de versión de calendario tiene mayor relevancia el concepto de fechas. Y luego, en segundo lugar y de manera opcional, una numeración. Es más... ¡en una distribución libre incluso la numeración puede carecer de significado y ser irrelevante! Pero en un escenario de Roadmap la numeración es necesaria ya que da sentido a la formalidad y se impone un hito, una marca alcanzable.

Por su parte, en un escenario versionado exclusivamente numérico la fecha adquiere menor relevancia y hasta el punto que solo parece ser "decorativa" y en su lugar adquiere más sentido práctico mencionarla en el ChangeLog.

 

Pero además <revision> adquiere una visión diferente. En liberaciones libres <revision> va acompañando a las fechas/momentos, incrementandose según se va dando la numeración interna Es decir hay correspondencia entre fecha/momento y revisión: fecha1->revision1, fecha2->revision2, ... . Ahora bien, si se añade <release> y/o <subrelease> y lo hacemos público la revisión cambia de significado, y estamos indicando que cada tanto (y cada vez que sale una liberación o subliberación) reiniciamos el contador.

¿Porqué esta dicotomia?

Porque hay situaciones en la que podemos prescindir de numeración de liberaciones si lo que pretendemos es hacer un producto "infinito" o no queremos/sabemos darle un ciclo de vida (calendario libre es una buena alternativa para esto) Y habrá situaciones en las que debemos darle un ciclo de vida y decir: "Hasta aquí llegaste versión X".

Algo similar sucede con Roadmap y/o con un Sistema exclusivamente numérico: ya que estamos definiendo un <release><subrelease> y/o opcionalmente un estado, <revision> se ve afectado. Tenemos un ciclo de vida, con más o menos restricciones, pero un ciclo de vida al fin.

Y si en verdad tenemos pensado permitir que una liberación publicada X esté en un estado Y, cuya versión sería X-Y entonces, debemos ajustar lo que entendemos por <revision>. Si sacamos una versión "no final", en cierta forma estamos definiendo un revisión más que no la hemos definido, necesariamente ni obligadamente, como un cambio de <breaking>..<path> (recuerden del documento el concepto de <improvement>), por lo que es una publicación más y necesariamente debemos contarla y diferenciarla.

La lección: <revision> va a depender del estado del software.

 

• <revision> incrementa también cuando se pasa de un estado a otro.
• El formato para <compilerversion> se modificará para manejar el nuevo sistema de salto.
• Para <state> se agrega una nueva tabla de metadata. Se podrá optar por el diseño tradicional, el griego (el nuevo), o bien definir la propia tabla, tal como ya estaba previsto. Y se formalizará el orden de precedencia 0 para las versiones catalogadas como final, aunque su uso es opcional ya que se puede dar por sobre entendido.

 

Tradicional: snapshot | pre_alpha; alpha; private_beta | closed_beta; public_beta | open_beta; beta; release_candidate | pre_release; final.

Griego: alpha; beta; gamma, delta.

 

Si se tuviera que hablar de equivalencia entre ambos podríamos decir que el estado alpha en el griego se coresponde al estado alpha y menores en el tradicional. De forma análoga para beta, que le correspondería a todos los estados beta en el tradicional. Y sólo nos deja a gamma para corresponderse a los estados pre_release | release_candidate y a delta para la versión final o definitiva.

 

Si bien no es muy común el metadata en griego. Hay algún que otro software que sigue este estilo, y no estaría mal incluirlo ya que estamos.

 

Por el momento en todo esto estoy trabajando

Como pueden apreciar es un cambio nada despreciable. Si bien hay cosas que se romperán, sus axiomas y las bases siguen siendo válidas.

 

Saludos,