Nombre en vez de numeración en versiones
 

Hola, saludos a todo el equipo.

Tras la pronta llegada de la nueva versión de Android, la que recibe el nombre de Marshmallow (Apple Pie, Banana Bread, Cupcake, Donut, Eclair, etc), ¿que opinan al respecto en cuanto a colocar nombres en vez del número de la compilación o versión?

La primera vez que oí al respecto, fue con las versiones de Ubuntu, tales como Warty Warthog, Hoary Hedgehog, Breezy Badger, etc. También me "sorprendió" cuando salio Windows 95, aunque en principio correspondía al año de lanzamiento, luego descubrí que tenía más que ver con la compilación tras la versión anterior de Windows 3.11. Es decir Windows 95, era en realidad Windows 3.95, lo mismo para Windows 3.98, luego 4, 5, 6, 7, 8, 8.1 y 10. aunque el 5 y 6 recibieron el nombre de XP y Vista.

También en productos menos masivos como Cobian Backup como Luz de Luna, Black Moon, Amanita, Boletus y Gravity.

Algunos siguen una lógica tanto en sus nombres como iniciales en el caso de Ubuntu. Otras, no las sé.

¿Lo hacen en sus proyectos? ¿Le da un toque al asunto? ¿Que opinan al respecto?

Más que nombres de las versiones son el nombre en clave designado para el proyecto en sí.
El nombre es secundario, y se los pone debido a que por lo general no se sabe realmente cual va a ser la versión definitiva. Entonces en lugar de decir Sistema X.Y.Z.nnnnA o llegarlo a confundir con el .Y.nnnnB y continuar con una numeración/serie que va a ir cambiando cada 2 por 3 se lo llama por el nombre clave.

No se si tiene sus lógicas o algún patrón. Quizá si, no estoy tan familiarizado. Es un detalle menor, siendo sincero. ¿A Alguien le importará como carajos le pusiste el nombre a la aplicación o al proyecto? Pocos la verdad... Es más importante en tener un producto que sea comercial, que funcione y cumpla con lo prometido, que haya sido elaborado siguiendo un buen esquema de trabajo y bien pensado, que haya sido probado intensamiente, etc.

Si a ti te resulta cómodo pues hazlo. Usarlo o no usarlo no te va a cambiar la cosa... a lo sumo unos puntitos más para el "cartelito" como para decir "Oh, mira, este es el proyecto <Ponga el nombre más Pro, pegadizo y fácil de recordar que le cante aquí>" y sentirse que se te sube el ego porque sigues la moda y eres uno más de los "Pro".

Saludos,

Es cuestión de gustos, obviamente. A mí me gustan los nombres, aunque luego no los recuerdo, ejemplo, conozco la versión de mi ubuntu pero no sé qué nombre tiene.

Para mí, bautizarlas es complicarme el trabajo.

Cualquier nombre no te va a decir nada cuando un cliente te llame y le preguntes. Sin embargo si usas cualquier tipo de numeración, puedes tener un registro mental que a partir de la 3.5 hiciste un cambio grande.

Aunque para esto es útil el sistema de incrementar la versión de compilación, tampoco lo he usado nunca, más que nada por si se me olvida cambiarlo, o hago un build antes de tiempo y las cnpacks me incrementan ese número automáticamente (existe esa opción). Yo prefiero tirar de archivo de texto con la versión ahí.

También puede servir, como hace ubuntu, el mes y año en que salió la versión. El "3.5" no le dice nada al cliente, pero "Marzo de 2012" le dice al cliente que lleva 3 años sin usar las actualizaciones, puede que te convenga o no.

Saludos

En el asunto de versionado, este es uno de los estándares mas utiles:

http://semver.org/

El tema es que una vez que hay algo publico, es importante tener claro que es realmente una "version".

Con respecto a los nombres? A mi me parecen cool!. Pero son mas una cosa de marketing o gusto, y son tangenciales al tema de versionado. Uno quiere que las versiones sean frias, lógicas & predecibles.

Con los nombres de marketing? A mi me gustan los nombres poco convencionales! (Ej de proyectos mios: BestSeller, Teleport, TablaM, Mutis.... y eso que porque son cosas que ofrezco a clientes no me atrevo a ir mas alla!)...

---

Hay algun patron? Normalmente si.

Por ejemplo, OSX siguio la linea de "usemos gatos grandes". Ahora estan en "usemos nombres de lugares de california". Normalmente el equipo se pone en algun tema asi.

Es muy similar al nombrado de servers. A mi me gusta "usemos nombres relacionados con ciencia ficcion", asi que mi WIFI es "Galactica/Hiperespacio", mis equipos se llaman "Avenger, Skywalker, Falcon, DarthVader, IronMan, FireFly, ...."

Porque tener un equipo llamado "Servidor 1"? .... pfffffffff

Nada de nota mental, que luego quedan al olvido. O se lleva un buen control de versión o nada. ¿Tu nota mental te va a decir exactamente que cambios se hicieron o te va a orientar por donde está el fallo x? Muy difícil, y cada vez es más costoso sostener ese esfuerzo mental en la medida en que se empieza a agrandar el sistema y/o se está trabajando con varios proyectos en paralelo.
Ordenar la casa primero. Tener un sistema prolijo. Esto es tan importante como el análisis, las pruebas y la programación.

Ubuntu (y familia) tiene un sistema bastante simple de versionado Saca una versión X.04 y la otra X.10 con unos meses de diferencia. La x.04 corresponde a lo que se conoce como "release candidate" mientras que la .10 a la definitiva. En su sistema de versión no aparece nada de mes o año, que sea más fácil de asociar la versión al año y/o mes es otra cosa. Luego es que al proyecto de cada año, al preparar una nueva X+1, le da un nombre clave que sigue un criterio alfabético de un animal y un adjetivo asociado al mismo.
Luego es que existe lo que se llama el sistema no-LTS y LTS que es sistema de soporte de medio y largo plazo respectivamente (9 meses y 5 años si no me equivoco) que acompaña al sistema de numeración.
Asi por ejemplo, 10.04 es LTS mientras que 10.10 es no-LTS.

No es exactamente así.
Hay una versión nueva cada 6 meses. Una en abril (04 ) y otra en octubre (10), todos los años.

En cuanto a las versiones LTS, copio de la wikipedia:

Bueno, tan mal no estuve... viniendo de alguien que tiene poco Linux encima ;) Al menos ofrecí una mejor descripción del sistema de versión de Ubuntu que los que me han precedido. Con eso me doy por satisfecho. :p

Por el tema del .04 y .10 tenía entendido que por lo general la versión .04 se la considera una versión "candidate" y de prueba que se va refinando hasta llegar a la .10 que suele ser una versión "definitiva" y estable.

Todos los días se aprende algo :)

Yo le hago así y combino las dos formas, a la fecha me ha funcionado:

Versionado tradicional:
4 enteros separados por punto: version mayor. version menor (mejoras). correcciones. hotfixes
Nombre clave: solo para la versión mayor.

entonces:

Version 6.7.0.1
Nombre clave: Gluck

Version 6.7.2.1
Nombre clave: Gluck

Version 7.0.1.1
Nombre Clave: Rossini

El nombre clave solo me indica una versión mayor, la cual por lo regular no es compatible totalmente hacia atrás (ojo: yo desarrollo software administrativo no SO).
Ningún esquema de versionado sirve si no se utilizar un sistema control de versiones, no tiene sentido uno sin el otro. Si no usas ni SVN, Git o Mercurial o similar para que te molestas en ponerle numeritos a tus versiones?

A mi el numero tampoco me dice nada. Al menos desde que uso control de versiones (git) el numero o nombre solamente me sirve para saber que es lo que esta bajado en la casa del cliente comparado con la ultima version (head)

Yo tambien creo que lo mas "cool" es combinar las dos maneras como comentan arriba. De hecho asi es como lo hace Android (4.4 --> Kit Kat, 5.0 Lollipop, etc)

Hola,

Yo reconozco que no usar control de versiones en todos mis proyectos me cuesta más de un dolor de cabeza. Desde hace tiempo incluyo la fecha en las versiones de mis programas. La cosa es que suelo actualizarlos con mucha, quizá demasiada frecuencia, y así no cambio de versión (1.0) pero sí de fecha. Así los archivos "historial" de mis programas contienen títulos como "1.0 (08/29/2005)". Y más abajo puede haber otro título tal que "1.0 (08/27/2005)".

Tengo para mí que no es la mejor manera de hacer las cosas. Reconozco que no he pensado muy seriamente en ello. Creo que números de versión como los que menciona Azidrain arriba podrían estar bien. Respecto de nombrar las versiones, me temo que alguna vez he caído en la moda, puesto que así lo he visto yo con mis cortas miras. Algunos proyectos los nombré o nombré sus versiones, pero, actualmente no lo hago.

Usar mercurial es muy facil (en comparacion con git) y su uso es tan bueno para proyectos solos como acompañados por otros. Yo aprendi con

http://hginit.com/

Y uso esta herramienta de forma visual (aunque casi todo lo hago en el terminal, para caso mas avanzados, para hacer diff y resolver conflictos es muy util):

https://www.sourcetreeapp.com/

Yo he usado varios, el último fue jedi vcs, porque se integraba dentro del propio delphi. Y resultaba muy cómodo.
Ahora no sé qué usar, no encuentro la forma de hacer algo "simple". Me explico: yo solo, varios proyectos, cada proyecto puede tener varias versiones y, lo principal, cada versión puede tener varios ficheros adaptados para distintos clientes.
Quisiera poder elegir algo así como: proyecto xxx del cliente yyy, y que si modifico algo del proyecto xxx se actualice en el de todos los clientes de ese proyecto. Pero si un cliente tiene un fichero adaptado para él, que esos no se cambie lo que esté adaptado para él, solamente lo que es genérico para todos.

Buenas Azid, están pendientes unos tragos. ;)

En el trabajo usamos Apache Subversion (SVN) integrado a RAD Studio para el control de versiones. Pero he de contradecir tu afirmación, ya que sí tiene sentido usar un esquema de versiones aunque no cuentes con un sistema como los que mencionas. Vaya, hace algunos ayeres numeraba las versiones de una pequeña aplicación de gestión sin necesidad de ese tipo de sistemas, y hacerlo era bastante útil. :)

Saludos apagando el fuego del dogma.

Al González.

Casimiro, en tu caso podría convenirte un archivo de proyecto por cliente (destinatario). Tratándose de proyectos Delphi, con un search path personalizado para cada uno, de tal forma que ahí aparezcan las rutas de directorio de las bibliotecas comunes (en segundo lugar) junto con las rutas de directorio de lo que es particular de ese destinatario (en primer lugar).

Aunque no creo que sea buena práctica mantener un mismo archivo de código duplicado y distinguido por destino de la aplicación. En todo caso hay que revisar ese archivo de código y hacerle lo necesario para volverlo más flexible (parametrizable), guardando las configuraciones en otro tipo de medios, como archivos .Ini, Registro de Windows o la propia base de datos.

Un saludo y pendiente un comunicado. ;)

Al González.

Yo lo hago con git y las llamadas branch:

Por defecto se crea una branch master en donde esta el proyecto llamemos "principal"
Luego por cada cliente que tiene una modificacion particular, se crea un branch a partir de una existente, por ejemplo de master.

Entonces ahi en esa branch es en donde haces las modificaciones para "pepito" y el resto ni se entera. De hecho al andar pasando entre un branch y otra (git switch branch) lo que realmente sucede es que los archivos con los que trabajas localmente pasan a ser los de la branch a la que cambiaste

Ej: Estabas en "pepito", haces switch a "master" y todo lo que agregaste nuevo en pepito no va aparecer en el disco fisicamente. No vas a tener un NuevoFormAgregado.pas. Logicamente si volves a pepito si va a estar. En ese sentido se mantiene la estructura simple y no tenes que andar comiendote la cabeza pensando "esto era de quien???"

Lo unico que no es automatico es el tema de, llamemosle "herencia". Para que se propagen los cambios es necesario hacer merge/cherry pick. Es decir, "alimentarte" de todos los nuevos cambios (commits) que queres que se reflejen. Esto lo tenes que hacer en CADA branch; podes pickear commits de cualquier brach, incluso de otro repositorio

Sí, Al, gracias, más o menos es lo que hago, aunque no resulta muy eficiente con distintos parámetros para mantener el código para un cliente u otro. Pero no he encontrado nada mejor hasta ahora. Saludos ^\||/
PD. Por cierto, no es con Delphi, desde hace unos años estoy haciendo "cositas" para Android. Cosas de la vida, que te lleva de un lado a otro y todo cambia por completo cuando menos te lo esperas.

Lo que comentas parece interesante, pero todos los sistemas de control de versiones que he visto me resultan engorrosos para mantener varios proyectos con distintas versiones y distintas subversiones, ¿usas algún entorno gráfico para usar Git o todo mediante comandos?

Gracias, voy a echarle un vistazo :)