TODO

Started by SplinterGU, November 28, 2008, 06:08:30 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

josebita

Algo como 1.49.20080506 lo veo un poco redundante, porque sabiendo el número de revisión la fecha lo único que te dice es cuándo se compiló, que no sé si hace mucha falta.

Pero vamos, que como lo veas. Mis nombres del PPA son bastante más largos (0.93svn20090503, por ejemplo :), también es cierto que el usuario no los usa para nada, en general).

DCelso

Entonces no es redundante ¿no? Redundante sería si se volviera a repetir un dato, te refieres más bien a que es fútil,

http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=redundante

http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=f%C3%BAtil

:D, yo y mis defensas/problemas con mi idioma nativo.

PD: Dejo esto en el aire, ¿está bien dicho "veinte y dos"?
Monstruos Diabólicos

"A PAck of classic GAMEs For BennuGD" en desarrollo
http://code.google.com/p/apagame4be/

TYCO

#107
Sin documentación en modo offline (sin internet), no debería salir la versión 1.0. Ya sea en un PDF u otro formato.

Con que se llamará v0.94 Build 231, sería suficiente. A grandes cambios: 0.95 Build xxx, a pequeños cambios: 0.94 Build 290. Hay varios programas que lo indican así, no sería el primero.

Algo sencillo y conciso.

PD: Si está bien dicho DCELSO.
Veintidós.
1. adj. Veinte y dos.
2. adj. Vigésimo segundo. Número veintidós. Año veintidós. Apl. a los días del mes, u. t. c. s. El veintidós de mayo
3. m. Conjunto de signos o cifras con que se representa el número "veintidós".
Programador, Escritor/Guionista y Deportista.

Todo Modo Gráfico tiene por detrás una Línea de Comandos.

SnowCraft Remake (100%)
Rally Mortal (87%)

DCelso

lo de la documentación offline lo veo fácil de hacer, usas  teleport pro y te descargas la wiki y la comprimes en un zip,

En cuanto a mi pregunta dije "veinte y dos", ya sé que está bien veintidos que es lo que buscaste en en la rae.
Date cuenta que está pendiente de revisión, revísalo de nuevo y dale al botón azul que hay arriba a la derecha y verás el cambio de esa palabra para la 23ª Edición.

De ahí de nuevo que lance mi pregunta.

PD: te he cambiado una b que teniás por ahí que me dañaba la vista :D, así que por este motivo verás que tu post está editado.
Monstruos Diabólicos

"A PAck of classic GAMEs For BennuGD" en desarrollo
http://code.google.com/p/apagame4be/

splinter_work

Quote from: DCelso on May 06, 2009, 02:12:37 PM
Un poco largo diría yo, pero que mas da :D.
De todas formas le veo un problemilla, que quizás no sea tan problemilla pero la dependencia al número de revisión de subversion daría lugar a binarios alejados en números por ejemplo si haces 8 subidas separadas sin crear binarios y luego mas adelance creas uno saltarías así como de la versión 1.49.20080506  a la versión 1.57.20080608 (fecha inventada) y los usuarios no puestos en el tema preguntarían por las versiones intermedias.
También pasarían cosas como estas, en la versión 2 lo que sea, el segundo número seguiría incrementándose por donde quedó
versión 1.59 - vesión 2.60. Y como resultado pasaría que el usuario nuevo vería la falta de versiones intermedias.

Como conclusión, normalmente se separan las nomenclaturas de control de versiones a las nomenclaturas de entrega final de binarios o bién se usa el mismo número para ambas, no se entremezclan nomenclaturas porque da margen a error.
Por ejemplo binarios de la release 48 de svn, o binarios de la versión 1.1.5, pero nunca binarios de la versión 1.1.48 porque puede pasar que cambiese a 1.2.50 en vez de pasar a la 1.2.0.
Lo normal es resetear números inferiores al cambiar a versión superior, podeis ver ejemplos en la mayoría de programas conocidos. Si por ejemplo ejecutais el comando ver en windowx xp vereis algo como 5.1.2600, el último número es el "build" si haceis lo mismo en un xp con service pack ese último número cambia, ya que es el mismo programa pero con mejoras no significativas. en cambio si lo haces a windows vista verás que empieza de nuevo 6.0.1000, no sigue por la dosmilypico.

El número final "build" normalmente es incrementado automáticamente por los programas de compilación de alto nivel tipo borland c++builder, delphi, visual c++. Y se incrementa por cada vez que tocas el botón "build and compile".
Lo que quiere decir,que representa el número de veces que ha sido ejecutado dentro del entorno de programación para pruebas de resultados del programador.

Pero vamos, eso es lo que tengo yo entendido, no tiene porqué cumplirse siempre porque hay muchas formas distintas de llevar el versionado y no está muy estandarizado, cada uno suele seguir su propio criterio o adoptar el que les imponen las reglas de programación.

Con ésto solo intento explicar los problemas que le veo a tu propuesta Splinter.

Yo no le veo ningun problema... mira Ubuntu, saco la version 8.04, luego la 8.10, ahora la 9.04... esto es porque ellos versionan usando <año>.<mes> y sacan una release cada 6 meses...
Nada tiene de malo que nosotros hagamos <version del proyecto>.<revision>.<fecha> o <version del proyecto>.<fecha>.<revision>

splinter_work

Quote from: josebita on May 06, 2009, 02:34:57 PM
Algo como 1.49.20080506 lo veo un poco redundante, porque sabiendo el número de revisión la fecha lo único que te dice es cuándo se compiló, que no sé si hace mucha falta.

Pero vamos, que como lo veas. Mis nombres del PPA son bastante más largos (0.93svn20090503, por ejemplo :), también es cierto que el usuario no los usa para nada, en general).

la fecha del build es muy importante, tan importante como la revision.

josebita

Quote from: DCelso on May 06, 2009, 03:43:19 PM
Entonces no es redundante ¿no? Redundante sería si se volviera a repetir un dato, te refieres más bien a que es fútil,

http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=redundancia

http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=f%C3%BAtil

:D, yo y mis defensas/problemas con mi idioma nativo.

Me acojo a la tercera acepción de redundancia :). Sabiendo el número de revisión, en http://bennugd.svn.sourceforge.net/viewvc/bennugd?view=rev&revision=49 se puede saber la fecha y hora de commit, así como revisar los cambios y el registro de subida.

Quote from: splinter_work on May 06, 2009, 07:01:47 PM
la fecha del build es muy importante, tan importante como la revision.
Así sea; el que manda, manda :)

splinter_work

Je, bueno, tampoco tiene que ser dictatorial la decision... por eso pregunte...
Pero creo que la idea es que la revision y la fecha sean rapidamente identificables y no tener que ingresar a un svn para ver eso.
El usuario medio (el alto y el bajo tambien :P ) no sabe (y ni tiene por que saber ) que es un svn.

Windgate

...¿Qué es un SVN?... Aunque sea así por encima... Suelo llevar control de versiones, pero simplemente empiezo por 0.0 y voy sumando 0.1 a cada nueva versión... ¿Es algún sistema de numeración de versiones o algo de eso?
Iván García Subero. Programador, profesor de informática, monitor de actividades culturales y presidente de TRINIT Asociación de Informáticos de Zaragoza. http://trinit.es

l1nk3rn3l

bennu es tan estable que ya empecemos con la 1.x
bennu ya no tiene nada parecido a fenix 0.76 del año 2000

recuerdo que corria el pang con esa version y
bueno trataba de hacer algo interesante y la SDL
ocasionaba errores de vez en cuando,,

yo creo que bennu ya tiene madurez

porque no llamarlo bennu v1.0
en lugar de bennu r50


panreyes

Voto por utilizar esta nomenclatura más que estándar:
CAMBIOSGRANDES.PACKDENUEVASFEATURES.BUGSOFEATURESMENORES (no sé si m'explico xD)

Empezando por: Bennu 1.0.0

Bugs corregidos: x.y.z+1
Nuevas funcionalidades: x.y+1.z=0
Cambios transcendentales (no se esperan en mucho tiempo, por ahora): x.y+1.z=0


Pero bueno, hablo sólo de las releases, para las builds sería, el x.y.z actual y detrás "build r$n"

DCelso

Ahí le has dado, te has explicado de PM, eso es lo que quería decir yo no me expresé del todo bien, veo que no soy el único que ha usado esa nomenclatura mas o menos estandarizada :D.

Con respecto a lo del SVN es subversion.
Es para control de versiones de archivos de código fuente, nada que ver con control de versionado de binarios soltados o liberados.


Monstruos Diabólicos

"A PAck of classic GAMEs For BennuGD" en desarrollo
http://code.google.com/p/apagame4be/

Windgate

Empezar con Bennu 1.0.0 y llevar el sistema de numerado propuesto por PiXeL me parece correcto, he probado Bennu todo lo que he podido... Y lo considero estable y digno de una 1.0.0. (Aún estoy haciendo pruebas con structs, memoria dinámica y un spaghetti de punteros curioso, pero por ahora va bastante bien todo)

Si lo aceptamos... ¡¡¡Hay que celebrarlo!!!
Iván García Subero. Programador, profesor de informática, monitor de actividades culturales y presidente de TRINIT Asociación de Informáticos de Zaragoza. http://trinit.es

josebita

Me refería a que tampoco me iba a poner a discutir el sistema de numeració de versiones :).
Pero debo decir que estoy con Pixel; creo que es el sistema que usa más gente, sobre todo en programas libres.

SplinterGU

La idea que todos coincidimos (salvo uno) es que debemos sacar la version 1.

Convengamos que no necesitamos seguir la manada y tomar una nomenclatura de versionado especifica, lo importante es identificar facilmente si estoy con un ejecutable viejo o no, y a que revision del repositorio corresponde... despues detalles como saber si se hicieron o no 80 agregados o 500 fixes a una version, son datos estadisticos y anecdoticos, pero el saber a que version de fuentes corresponde y a la fecha en que fue liberado es importantisimo a la hora de asegurar compatibilidad con modulos o incluso para saber si tenemos tal o cual cosa corregida, cuantas no es un dato critico.

Resumiendo y combinando lo que todos decimos, propongo tomar la siguiente nomemclatura... (que para mi parecer es mas importante la parte que esta entre parentesis)

<version>.<new features>.<fixes sobre la ultima version feature> (Build YYMMDDr<revision>)

por ejemplo:

1.10.5 (Build 091025r48)

o

1.10.5 (091025r48)

o

1.10.5.091025r48
Download Lastest BennuGD Release: http://www.bennugd.org/node/2