[altnet-hispano] Cambio de Version

[Edgar Ramos]

Gente un saludo a todos, a continuacion mi inquietud

He desarrollado una aplicacion pequeña con nh version 2.1.0, y otros
librerias de utilidad como Castle Windsor 2.1.1, Common Service
Locator 1.0, y bueno algunos mas.

Despues de mover, quitar, poner, librerias, al final tuve un problema
de versiones, y vs2008 no me permitia ejecutar mi programa
Si lo admito, mezcle en mi folder donde tengo todas mis dependencias
versiones distintinas de algunas de mis librerias en uso, al final
deje todo con las versiones mas recientes y funciono

Y aqui la pregunta. Por ejemplo, si trabajo con nh 2.1.0 y luego (muy
pronto o para ayer) requiero cambiarme a nh 3.x.y, cual seria el
procedimiento correcto para hacer este cambio de versiones y no
afectar de alguna manera mi aplicacion que trabaja con la version
antigua, y requiero cambiarme y aprovechar todo lo que viene con la
nueva version

Pido disculpas si la pregunta debia plantearla en el foro de nh.

Por otro lado cual seria la metodologia (si la hay) a seguir para
versionar un producto (si la verdad suena basico pero ese es mi
nivel).

Si maniana procedo a crear un producto MiProdcuto.dll (1.0.0.0) en que
me sustento para pasar a algo similar a esto 1.0.1.0
2.1.1, 3.x.y.z, etc

El sustento logico para ir incrementando es el que no entiendo

Recuerdo que en la van de mercurial se hablaba de software que
trabajaba con este enfoque, o en definitiva se lo hace manualmente ?,
pero cual es la metodologia ?

Un saludo y gracias por sus comentarios

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispan...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.

[José F. Romaniello]

El 23 de mayo de 2010 13:53, Edgar Ramos <eramo...@gmail.com> escribió:

Y aqui la pregunta. Por ejemplo, si trabajo con nh 2.1.0 y luego (muy
pronto o para ayer) requiero cambiarme a nh 3.x.y, cual seria el
procedimiento correcto para hacer este cambio de versiones y no
afectar de alguna manera mi aplicacion que trabaja con la version
antigua, y requiero cambiarme y aprovechar todo lo que viene con la
nueva version

Yo, y la mayoría de personas que conozco, no agregan referencias a nhibernate.dll que esta en el directorio c:\program files......

lo que usualmente hacemos es tener una carpeta al mismo nivel del archivo de solución llamada SharedLibs, o simplemente Libs.

MiSolucion.sln

Libs\   --> aqui tengo nhibernate.dll castle.windsor.dll castle.dynamicproxy.dll y así ....

MiProryecto1\

MiProyecto2\

MiProyecto3\

las referencias siempre las agrego a la carpeta LIBS, ojo... no se copia a la carpeta libs, algo como mscorlib.dll, jejeje :)

Actualizar de Nh2 a Nh3 significa dos pasos:

1. pisar nhibernate.dll que esta en la carpeta libs, con la nueva versión de la dll.
2. correr todos mis tests y asegurarme que todo funcione bien.

También tenes que tener cuidado con las dependencias entre proyectos opensource, ya que la versión 3 de nhibernate, que esta en el trunk, tiene una parte (una dll llamada bytecode provider) que depende de una versión especifica de Castle. Así que podes mirar en su carpeta Libs para ver cual esta usando etc.

 

Pido disculpas si la pregunta debia plantearla en el foro de nh.

Por otro lado cual seria la metodologia (si la hay) a seguir para
versionar un producto (si la verdad suena basico pero ese es mi
nivel).

Si maniana procedo a crear un producto MiProdcuto.dll (1.0.0.0) en que
me sustento para pasar a algo similar a esto 1.0.1.0
2.1.1, 3.x.y.z, etc

El sustento logico para ir incrementando es el que no entiendo

Hay mil formas; http://en.wikipedia.org/wiki/Software_versioning .. En la empresa donde trabajo usamos una parecida a los proyectos open source "Major"."Minor"."Revisión"

Major, lo incrementas cuando hubo un cambio importante en funcionalidades importantes, o bien nuevas funcionalidades importantes fueron agregadas.

Minor, lo incrementas cuando hubo un cambio menor, o solamente arreglos de bugs.

Revisión; es el número de revisión en subversión.... (y en Mercurial? o GIT?, que no existe un número de revisión?? no tengo idea)

 

Recuerdo que en la van de mercurial se hablaba de software que
trabajaba con este enfoque, o en definitiva se lo hace manualmente ?,
pero cual es la metodologia ?

Un saludo y gracias por sus comentarios

[Edgar Ramos]

Gracias nuevamente José, cuando vengas por Ecuador te organizo un tour
chevere para que conozcas este mi hermoso país

Con respecto a lo siguiente

------------------
SharedLibs: Tambien la utilizo, vi en un ejemplo y me parecio muy bien
el enfoque, se ve que ando por buen camino lado
------------------

proyectos open source "Major"."Minor"."Revisión"

------------------

Seria bueno conocer por ejemplo con la gente de mercurial, como llevan
a cabo este versionado

Revizando el blog de Fabio, me encontre con lo siguiente

http://fabiomaulo.blogspot.com/2008/11/nh-with-multiple-assembly-versions-in.html

Y me preguntaba, en verdad si mi dominio cambia, esto es muy
frecuente, es normal hacer algo como esto

--------------------------------
Domain version 1.0.0.0

public class Person
{
public virtual int Id { get; set; }
public virtual string FirstName { get; set; }
public virtual string LastName { get; set; }

public virtual string FullName
{
get { return string.Concat(FirstName, "-", LastName); }
}
}
------------------------------
Domain version 1.1.0.0

public class Person
{
public virtual int Id { get; set; }
public virtual string FirstName { get; set; }
public virtual string LastName { get; set; }

public virtual string FullName
{
get { return string.Concat(LastName, "*", FirstName); }
}
}
------------------------------
Para luego proceder con esto

<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"
applies-to="v2.0.50727">
<qualifyAssembly partialName="Company.Domain"
fullName="Company.Domain, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=5c41dce254553643" />
<dependentAssembly>
<assemblyIdentity name="Company.Domain"
publicKeyToken="5c41dce254553643"/>
<bindingRedirect oldVersion="1.0.0.0"
newVersion="1.1.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>

?

Saludos




El día 23 de mayo de 2010 17:00, José F. Romaniello
<jfroma...@gmail.com> escribió:

[Nelo Pauselli]

Hola Edgar, en mi opinión...

respecto a las versiones de dll que usas en cada desarrollo, creo que
tener una carpeta lib en cada uno con las dlls que usas es lo mas
simple y standard.

respecto al procedimiento para actualizar la versión de una dll,
podría ser leer la documentación de la versión y ver que rompe con la
versión anterior (breaking changes), luego actualizar tus dlls, hacer
las actualizaciones que dice dicha documentación y volver a ejecutar
todos tus test. Aunque si confías en tus test, actualizá las dlls,
ejecutá los test y, si algo se rompe (da rojo) ahí mirá los breaking
changes.

respecto a la forma de versionar tus productos, bueno, pienso que los
team leaders que hay en el foro podrán darte una buena visión... Un
criterio para productos comerciales podría ser: el primero número
(major) lo cambiás cuando la licencia de la versión anterior de tu
producto ya no aplican, el segundo número (minor) lo incrementas si se
agregan funcionalidades, pero sin cambio de licencia. El tercer número
(revision) en cada compilación nueva que no cambia ninguna
funcionalidad para el cliente...

Saludos.
Nelo.

2010/5/23 Edgar Ramos <eramo...@gmail.com>: