Control de versiones (era Re: PHP - domxml_open_file())

[Rodrigo Fuentealba]

2006/10/11, Franco Catrin <fcatrin en tuxpan.com>:
> El mié, 11-10-2006 a las 14:59 -0400, Rodrigo Fuentealba escribió:
>
> > No necesito implementarlo, necesito entenderlo. Para mí es más lógico
> > usar la última versión de un software, que ha corregido errores. Eso
> > de "stable, unstable, devel" o "historical, current, next" o como se
> > llame, me significa un quebradero de cabeza.
>
> Es un poco off-topic pero el tema es interesante.

Bueno, tratándose de intentar comprender cómo se organiza el
desarrollo de aplicaciones Linux, puede quitarle en algo la
característica de off-topic.

> El software no tiene una linea unidimensional de desarrollo, al menos no
> el software con cierto grado de complejidad.

ajá.

> Si fuera unidimensional, simplemente tomas la ultima version y listo.
> Pero la realidad no es asi.  A medida que los requerimientos cambian hay
> partes del software que necesitan cambiar radicalmente, perdiendo la
> compatibilidad hacia atras, ademas que debes separar entre lo que estas
> "desarrollando" y lo que estas "estabilizando".

stable / devel.

> Por ejemplo, si tienes una aplicación que se construyó con un
> determinado conjunto de requerimientos (o feature set), la entregas, se
> acepta y se comienza a utilizar.

que es lo normal cuando uno desarrolla una aplicación.

> Esa aplicación se va estabilizando a medida que se corrigen bugs
> (version stable).  En el intertanto te piden implementar nuevas
> caracteristicas y comienzas a desarrollarlas.  Mientras estas en eso te
> piden un fix de un bug de la version que esta en uso... que haces??
> segun tu, le mandarias la ultima version! pero esa version tiene cosas
> que aun no has terminado y que ni siquiera estan probadas, ademas tiene
> cambios que han eliminado cosas que se estan utilizando
>
> Entonces no puedes tener una sola linea de desarrollo!!!!  No existe "la
> ultima version" porque la ultima version no esta terminada.  Tu ultima
> version que sirve tiene otro camino paralelo a esa (stable+bugfixes)
>
> Lo que haces en esos casos es mantener una rama estable (stable) en
> donde vas aplicando bugfixes, y tienes otra rama en donde estas
> desarrollando (unstable/devel).  Hasta que terminas los cambios y tu
> version unstable/devel se transforma en stable y estas listo para un
> nuevo ciclo de bugfix en esa version y probablemente desarrollo en otra
> version.

Me queda más que claro, gracias por tu tiempo y paciencia. Lo que
describiste aquí es "versión estable / versión de desarrollo", que es
para software más complejo. Puedo inferir, a partir de esto, que para
software cuya misión es más crítica (p. ej. Apache), se justifica el
seguir manteniendo la versión histórica por un tiempo más, ya que la
migración es en realidad mucho más compleja, por ser Apache una base
para muchisimas aplicaciones.

Tan simple y no lo había pensado así...

Gracias.

-- 
Rodrigo Fuentealba Cartes
Desarrollador de Sistemas Web
Registered User 387639 - http://counter.li.org