              Como elegir la version apropriada de FreeBSD

  El Proyecto de Documentacion de FreeBSD

   Copyright (c) 2005 El Proyecto de Documentacion de FreeBSD

   $FreeBSD:
   doc/es_ES.ISO8859-1/articles/version-guide/article.sgml,v 1.1
   2008/02/03 15:02:16 carvay Exp $

   FreeBSD is a registered trademark of the FreeBSD Foundation.

   Asi que ha decidido instalar FreeBSD. !Bienvenido! el proposito de
   este documento es ayudarle seleccionar la version apropriada.

   Traduccion de Gabor Ko:vesdan <gabor@FreeBSD.org>.

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

1 Introduccion

   Antes de decidir cual de las versiones de FreeBSD quiere usar es
   importante que comprenda los conceptos relacionados con el
   desarrollo y el proceso de Ingenieria de Releases (RE).

   FreeBSD se desarrolla gracias a un gran grupo de gente, casi
   siempre voluntarios. El codigo fuente del kernel, de las
   utilidades y de las bibliotecas mas comunes estan en un sistema de
   gestion de codigo del cual es posible descargarlo en cualquier
   momento. Aparte de esto, existen versiones (binarias) ya
   compiladas que se liberan cada poco tiempo. Una de estas versiones
   binarias cuidadosamente revisada sera en su momento declarada
   releases.

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

  1.1 Releases

   El nombre de las releases contiene un numero mayor de release y un
   numero menor de release.

     * El proposito de una release mayor es incluir nuevas funciones.
       Es inevitable que, al anadir nuevas funciones a FreeBSD o al
       quitarlas, sea necesario algunas veces perder la
       compatibilidad con versiones anteriores del sistema operativo.

     * El proposito de una release menor es ante todo corregir
       errores y mejorar el rendimiento y la estabilidad. Es
       importante mantener la compatibilidad entre releases menores
       tanto cuando se trata de codigo como con los programas
       ejecutables. Si se da la ocasion, se anaden nuevas
       caracteristicas a una release menor si estos principios se
       mantienen.

   No obstante, tenga en cuenta que una "release" es solamente una
   instantanea del arbol de codigo en un momento dado, gracias a lo
   cual se le da una etiqueta o tag. Por ejemplo, la etiqueta que el
   grupo de ingenieria de releases dio a la release 5.4 fue
   RELENG_5_4_0_RELEASE. El desarrollo tiene lugar bajo la etiqueta
   HEAD.

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

  1.2 Bifurcaciones

   En el tiempo de sacar cada release, se crea una rama, por ejemplo
   RELENG_5_4. Aunque el codigo bajo RELENG_5_4_0_RELEASE no cambien,
   los que estan bajo RELENG_5_4 si, al aplicar cambios en HEAD al
   corregir problemas de seguridad u otro tipo de fallo.

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

  1.3 STABLE y CURRENT

   Durante la vida de cada release mayor una rama individual puede
   convertirse en STABLE. Esto indica que el Proyecto FreeBSD cree
   que la rama ha demostrado suficiente calidad para que la mayoria
   de los usuarios puedan usarla. Las ramas que necesitan mas pruebas
   antes de que pueda usarlas cualquiera reciben el nombre de
   CURRENT.

     Note: El Proyecto FreeBSD no puede garantizar que el software
     que se distribuye sea todo lo estable que sea necesario para
     cualquier necesidad o uso. Es el usuario quien tiene la ultima
     palabra sobre esto. Por favor, tenga muy en cuenta que el
     proyecto lo forman voluntarios y no puede ofrecer ningun tipo de
     garantia.

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

  1.4 Ports y packages

   Aparte de los ficheros que se distribuyen del modo ya descrito
   antes, FreeBSD permite el uso de miles de aplicaciones fruto del
   trabajo de desarrolladores que no forman parte del proyecto.
   Podemos citar como ejemplos sistemas de ventanas, navegadores web,
   programas de correo electronico, software ofimatico, etc.) El
   proyecto en si no desarrolla estos programas, solamente el
   "framework" que permite que estos puedan instalarse; este
   "framework" recibe el nombre de Coleccion de Ports). Se pueden
   instalar aplicaciones desde el codigo fuente si su licencia
   permite este tipo de redistribucion; es lo que en FreeBSD se
   llaman los ports)), o como software compilado si esta permitido
   distribuirlos como tal, en cuyo caso reciben el nombre de
   packages.

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

2 El calendario de releases anteriores

   Durante el desarrollo de la release 5.X de FreeBSD hubo que
   aprender en carne propia muchas lecciones que solamente pudieron
   verse con posterioridad. Los objetivos de la serie 5.X fueron muy
   ambiciosos. Veamos algunos:

     * Ofrecer soporte para maquinas dotadas de multiproceso
       simetrico (Symmetric MultiProcessing, o SMP)

     * Mejoras del rendimiento gracias a la adopcion de una nueva
       estrategia de gestion de recursos en el kernel

     * Anadir numerosas arquitecturas de procesador

     * Introduccion de un nuevo modelo de "threading"

     * Introduccion de un nuevo "scheduler"

     * Anadir soporte de nuevas tecnologias como la gestion de
       energia (especialmente importante en maquinas portatiles), y
       sobre todo

     * no declarar ninguna version como STABLE hasta que estas tareas
       no se hubieran terminado

   Esto llevo al problema de que habia varios anos de diferencia
   entre el momento en el que 4.X se declaro STABLE y el momento en
   el que 5.X se llego a STABLE. Esta circunstancia tuvo diversos
   efectos no deseados:

     * El numero funciones cambiadas simultaneamente hizo muy dificil
       aislar esos cambios para hacerlos compatibles con las
       versiones anteriores a la creacio de la rama STABLE.

     * Eso significo que los usuarios que necesitaban imperiosamente
       una nueva funcion en particular (por ejemplo el poder ejecutar
       FreeBSD en hardware moderno) estaban obligados a usar (por
       ejemplo) FreeBSD 5.2.1 a pesar de que oficialmente era una
       release de uso exclusivo de desarrolladores, y sin tener en
       cuenta el hecho de que una release CURRENT no cumplia sus
       demandas.

     * En los casos en los que se consiguio la compatibilidad con
       versiones anteriores los desarrolladores se encontraron con
       otro problema al intentar adaptar ciertas caracteristicas a
       una version que ellos mismos hacia tiempo que no usaban como
       su plataforma de desarrollo principal.

     * El retraso tambien provoco que cuando 5.3 se declaro nueva
       release STABLE la cantidad acumulada de cambios hizo la
       actualizacion complicada.

   A decir verdad, nadie estaba contento con el resultado.

   Las lecciones que se aprendieron de todo esto fueron:

     * Las nuevas releases mayores deben tener meno cambios
       estructurales importantes y deben publicarse con mayor
       frecuencia.

     * Siempre que sea posible los cambios estructurales deben
       aislarse unos de otros. Esto obliga a que parte del desarrollo
       tengan lugar fuera del arbol principal y que se integren
       solamente cuando no afecten a otros procesos simultaneos de
       desarrollo.

     * Las releases mayores deben tener fecha de salida propia no
       dependiente de la fecha de entrega asignada a un cambio
       estructural. Si un cambio estructural no esta listo a tiempo
       se incluira desactivado por omision y sera incluido en la
       siguiente release.

   Al publicar grupos de cambios mas pequenos y de una forma mas
   habitual se intenta tambien dedicar menos tiempo y esfuerzo
   aplicando nuevas caracteristicas de HEAD a a la ultima version
   STABLE (y poder asi usar dichas nuevas caracteristicas en mas de
   una version mayor); aun mas, al estar los cambios mas aislados el
   riesgo de provocar nuevos problemas de seguridad es mucho menor.

   Ademas, el concentrarse en una fecha y no en la consecucion de una
   caracteristica lista para integrarse en el sistema, es mas facil
   planificar para el futuro tanto para los usuarios como a los
   desarrolladores de aplicaciones ajenas al proyecto y, como no,
   para los desarrolladores de FreeBSD.

   Estas razones (y no el intentar ir a la par de las versiones
   mayores de otro sistema operativo) son el principal motivo del
   cambio en el calendario de liberacion de versiones de FreeBSD.

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

3 Calendario de releases de aqui en adelante

   Estos son los objetivos actuales del calendario del Proyecto:

     * Sacar uan release mayor cada 18 meses

     * Sacar una release menor cada 4 meses

     * Ofrecer paquetes compilados para la release menor mas reciente
       de cada release mayor

     * Ofrecer actualizaciones de seguridad y otras correcciones de
       fallos criticos para las versiones menores mas recientes de
       cada version mayor (que reciben el nombre de ramas de
       seguridad).

   Dado el gran numero de combinaciones de versiones instalables no
   es posible dar soporte a todas las releases. Esto es, en parte,
   debido a la cantidad limitada de maquinas de las que el Proyecto
   puede disponer, pero sobre todo a que la cantidad de voluntarios
   disponibles es limitada y su tiempo tambien.

   Si quiere leer mas sobre esto visite

   http://www.FreeBSD.org/releng/index.html#schedule

           Calendario de ingenieria de releases

   http://www.FreeBSD.org/security/security.html#supported-branches

           Calendario de ramas de seguridad

   Estos documentos profundizan en los porques de las decisiones
   tomadas sobre las ramas soportadas y el ciclo de vida de cada
   rama.

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

4 ?Como afectan estos factores a su decision?

   Los principales factores que influyen en su decision de que
   version instalar son, entre otros:

     * ?Que grado de estabilidad necesita su sistema?

     * ?Cuantos trabajo quiere dedicar a la actualizacion?

     * ?Durante cuanto tiempo va a usar una version dada entre una
       actualizacion y la que venga mas adelante?

     * ?Cuanta importancia le da a la seguridad de su sistema?

     * ?Instalara desde codigo fuente o binarios?

     * ?Va a participar en el desarrollo de FreeBSD?

   Aqui hay unas normas para ayudarle a tomar una decision:

     * Si sus necesidades son a corto plazo y quiere disfrutar del
       mas alto grado posible de estabilidad (y no puede dedicar
       muchos recursos a la actualizacion) probablemente lo mejor sea
       instalar la release STABLE mas reciente y dejarla como esta.
       Segun sean sus requisitos de seguridad puede o no aplicar los
       parches de seguridad que vayan apareciendo.

     * Si sus necesidades son a corto plazo y las nuevas
       caracteristicas o la seguridad son muy importantes para usted
       (y esta dispuesto a dedicar tiempo a las actualizaciones)
       deberia seguir la rama STABLE mas reciente.

     * Si no va a poner la maquina en produccion, va a dedicar tiempo
       a depurar unos cuantos problemas y en unos cuantos meses va a
       salir una nueva version mayor, puede instalar esa rama y
       ayudar al Proyecto haciendo pruebas para hacer el sistema mas
       estable y disponer de la mejor release posible a medio y largo
       plazo.

     * Solamente si quiere instalar desde codigo fuente y pasar
       tiempo depurando problemas del sistema base, enviar informes
       de fallos y utilizar las listas de correo dedicadas a esos
       fallos debe usar HEAD.

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

5 Conclusion

   Esperamos que este articulo haya servido de ayuda para que
   comprender el modelo de desarrollo de FreeBSD y pueda decidir que
   version se ajusta mas a sus necesidades.

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

          Puede descargar este y muchos otros documentos desde
                ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

Si tiene dudas sobre FreeBSD consulte la documentacion antes de escribir
                  a la lista <questions@FreeBSD.org>.
    Envie sus preguntas sobre la documentacion a <doc@FreeBSD.org>.
