diff options
| -rw-r--r-- | es_ES.ISO8859-1/articles/version-guide/Makefile | 19 | ||||
| -rw-r--r-- | es_ES.ISO8859-1/articles/version-guide/article.sgml | 442 |
2 files changed, 461 insertions, 0 deletions
diff --git a/es_ES.ISO8859-1/articles/version-guide/Makefile b/es_ES.ISO8859-1/articles/version-guide/Makefile new file mode 100644 index 0000000000..cf40e82e00 --- /dev/null +++ b/es_ES.ISO8859-1/articles/version-guide/Makefile @@ -0,0 +1,19 @@ +# +# $FreeBSD$ +# +# Article: FreeBSD Version Guide + +DOC?= article + +FORMATS?= html +WITH_ARTICLE_TOC?= YES + +INSTALL_COMPRESSED?= gz +INSTALL_ONLY_COMPRESSED?= + +SRCS= article.sgml + +URL_RELPREFIX?= ../../../.. +DOC_PREFIX?= ${.CURDIR}/../../.. + +.include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/es_ES.ISO8859-1/articles/version-guide/article.sgml b/es_ES.ISO8859-1/articles/version-guide/article.sgml new file mode 100644 index 0000000000..4c23b37217 --- /dev/null +++ b/es_ES.ISO8859-1/articles/version-guide/article.sgml @@ -0,0 +1,442 @@ +<!-- + The FreeBSD Documentation Project +--> + +<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [ +<!ENTITY % articles.ent PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Articles Entity Set//ES"> +%articles.ent; +<!-- +<!ENTITY art.re.pkgs '<ulink url="&url.articles.releng-packages;/article.html">La ingeniería de release de paquetes de distribuidores exteriores</ulink>'> +--> +]> + +<!-- The FreeBSD Spanish Documentation Project + Original Revision: r1.11 --> + +<article> + <title>Cómo elegir la versión apropriada de &os;</title> + + <articleinfo> + <authorgroup> + <author> + <surname>El Proyecto de Documentación de &os;</surname> + </author> + </authorgroup> + + <pubdate>$FreeBSD$</pubdate> + + <legalnotice id="trademarks" role="trademarks"> + &tm-attrib.freebsd; + </legalnotice> + + <copyright> + <year>2005</year> + <holder>El Proyecto de Documentación de &os;</holder> + </copyright> + + <abstract> + <para>Así que ha decidido instalar &os;. ¡Bienvenido! + el propósito de este documento es ayudarle seleccionar la + versión apropriada.</para> + + &trans.es.gabor; + + </abstract> + </articleinfo> + + <sect1 id="background"> + <title>Introducción</title> + + <para>Antes de decidir cuál de las versiones de &os; quiere + usar es importante que comprenda los conceptos relacionados con + el desarrollo y el proceso de Ingeniería de Releases + (<literal>RE</literal>).</para> + + <para>&os; se desarrolla gracias a un gran grupo de gente, + casi siempre voluntarios. El código fuente del kernel, de las + utilidades y de las bibliotecas más + comúnes están en un <firstterm>sistema de + gestión de código</firstterm> del cual es posible + descargarlo en cualquier momento. Aparte de esto, existen versiones + (<literal>binarias</literal>) ya compiladas que se liberan + cada poco tiempo. Una de estas versiones binarias cuidadosamente + revisada será en su momento declarada + <firstterm>releases</firstterm>.</para> + + <sect2 id="releases"> + <title>Releases</title> + + <para>El nombre de las <literal>releases</literal> contiene un + <firstterm>número mayor de release</firstterm> y un + <firstterm>número menor de release</firstterm>.</para> + + <itemizedlist> + <listitem> + <para>El propósito de una release mayor es incluir + nuevas funciones. Es inevitable que, al añadir + nuevas funciones a &os; o al quitarlas, sea necesario algunas + veces perder la compatibilidad con versiones anteriores del + sistema operativo.</para> + </listitem> + + <listitem> + <para>El propósito 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 código como con los programas + ejecutables. Si se da la ocasión, se añaden nuevas + características a una release menor si estos principios + se mantienen.</para> + </listitem> + </itemizedlist> + + <para>No obstante, tenga en cuenta que una <quote>release</quote> + es solamente una instantánea del árbol de + código en un momento dado, gracias a lo cual se le da + una etiqueta o <emphasis>tag</emphasis>. Por ejemplo, la + etiqueta que el grupo de ingeniería de releases dio a la + release 5.4 fue <literal>RELENG_5_4_0_RELEASE</literal>. El + desarrollo tiene lugar bajo la etiqueta + <literal>HEAD</literal>.</para> + </sect2> + + <sect2 id="branches"> + <title>Bifurcaciones</title> + + <para>En el tiempo de sacar cada release, se crea una + <firstterm>rama</firstterm>, por ejemplo + <literal>RELENG_5_4</literal>. Aunque el código bajo + <literal>RELENG_5_4_0_RELEASE</literal> no cambien, + los que están bajo <literal>RELENG_5_4</literal> + sí, al aplicar cambios en <literal>HEAD</literal> + al corregir problemas de seguridad u otro tipo de fallo.</para> + </sect2> + + <sect2 id="stable-vs-current"> + <title><firstterm>STABLE</firstterm> y + <firstterm>CURRENT</firstterm></title> + + <para>Durante la vida de cada release mayor una rama + individual puede convertirse en <literal>STABLE</literal>. Esto + indica que el Proyecto &os; cree que la rama ha + demostrado suficiente calidad para que la mayoría de los + usuarios puedan usarla. Las ramas que necesitan más + pruebas antes de que pueda usarlas cualquiera reciben el nombre + de <literal>CURRENT</literal>.</para> + + <note><para>El Proyecto &os; no puede garantizar que el software + que se distribuye sea todo lo <emphasis>estable</emphasis> + que sea necesario para cualquier necesidad o uso. Es el usuario + quien tiene la última palabra sobre esto. Por favor, + tenga muy en cuenta que el proyecto lo forman voluntarios y no + puede ofrecer ningún tipo de garantía.</para></note> + </sect2> + + <sect2 id="ports-vs-packages"> + <title><firstterm>Ports</firstterm> y + <firstterm>packages</firstterm></title> + + <para>Aparte de los ficheros que se distribuyen del modo ya descrito + antes, &os; 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 electrónico, software ofimático, + etc.) El proyecto en sí no desarrolla estos programas, + solamente el <quote>framework</quote> que permite que éstos + puedan instalarse; este <quote>framework</quote> recibe el + nombre de <firstterm>Colección de Ports</firstterm>). + Se pueden instalar aplicaciones desde el código fuente si su + licencia permite este tipo de redistribución; es lo que en + &os; se llaman los <emphasis>ports</emphasis>)), o como software + compilado si está permitido distribuirlos como tal, en cuyo + caso reciben el nombre de <emphasis>packages</emphasis>.</para> + </sect2> + </sect1> + + <sect1 id="past-schedules"> + <title>El calendario de releases anteriores</title> + + <para>Durante el desarrollo de la release 5.X de &os; 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:</para> + + <itemizedlist> + <listitem> + <para>Ofrecer soporte para máquinas dotadas de + multiproceso simétrico (Symmetric MultiProcessing, + o SMP)</para> + </listitem> + + <listitem> + <para>Mejoras del rendimiento gracias a la adopción + de una nueva estrategia de gestión de recursos en el + kernel</para> + </listitem> + + <listitem> + <para>Añadir numerosas arquitecturas de procesador</para> + </listitem> + + <listitem> + <para>Introducción de un nuevo modelo de + <quote>threading</quote></para> + </listitem> + + <listitem> + <para>Introducción de un nuevo + <quote>scheduler</quote></para> + </listitem> + + <listitem> + <para>Añadir soporte de nuevas tecnologías como + la gestión de energía (especialmente importante en + máquinas portátiles), y sobre todo</para> + </listitem> + + <listitem> + <para>no declarar ninguna versión como + <literal>STABLE</literal> hasta que estas tareas no se + hubieran terminado</para> + </listitem> + </itemizedlist> + + <para>Esto llevó al problema de que había varios + años de diferencia entre el momento en el que 4.X + se declaró <literal>STABLE</literal> y el momento en el que + 5.X se llegó a <literal>STABLE</literal>. Esta circunstancia + tuvo diversos efectos no deseados:</para> + + <itemizedlist> + <listitem> + <para>El número funciones cambiadas simultáneamente + hizo muy difícil aislar esos cambios para hacerlos + compatibles con las versiones anteriores a la creació de + la rama <literal>STABLE</literal>.</para> + </listitem> + + <listitem> + <para>Eso significó que los usuarios que necesitaban + imperiosamente una nueva función en particular + (por ejemplo el poder ejecutar &os; en hardware moderno) + estaban obligados a usar (por ejemplo) &os; 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 <literal>CURRENT</literal> no cumplía sus + demandas.</para> + </listitem> + + <listitem> + <para>En los casos en los que se consiguió la compatibilidad + con versiones anteriores los desarrolladores se encontraron con otro + problema al intentar adaptar ciertas características a una + versión que ellos mismos hacía tiempo que no usaban + como su plataforma de desarrollo principal.</para> + </listitem> + + <listitem> + <para>El retraso también provocó que cuando 5.3 se + declaró nueva release <literal>STABLE</literal> la + cantidad acumulada de cambios hizo la actualización + complicada.</para> + </listitem> + </itemizedlist> + + <para>A decir verdad, nadie estaba contento con el resultado.</para> + + <para>Las lecciones que se aprendieron de todo esto fueron:</para> + + <itemizedlist> + <listitem> + <para>Las nuevas releases mayores deben tener meno cambios + estructurales importantes y deben publicarse con mayor + frecuencia.</para> + </listitem> + + <listitem> + <para>Siempre que sea posible los cambios estructurales deben + aislarse unos de otros. Esto obliga a que parte del + desarrollo tengan lugar fuera del árbol principal + y que se integren solamente cuando no afecten a otros + procesos simultáneos de desarrollo.</para> + </listitem> + + <listitem> + <para>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 + está listo a tiempo se incluirá desactivado + por omisión y será incluido en la siguiente + release.</para> + </listitem> + </itemizedlist> + + <para>Al publicar grupos de cambios más pequeños y + de una forma más habitual se intenta también dedicar + menos tiempo y esfuerzo aplicando nuevas características de + <literal>HEAD</literal> a a la última versión + <literal>STABLE</literal> (y poder así usar dichas + nuevas características en más de una versión + mayor); aún más, al estar los cambios más + aislados el riesgo de provocar nuevos problemas de seguridad es + mucho menor.</para> + + <para>Además, el concentrarse en una fecha y no en la + consecución de una característica lista para + integrarse en el sistema, es más fácil planificar + para el futuro tanto para los usuarios como a los desarrolladores + de aplicaciones ajenas al proyecto y, cómo no, para los + desarrolladores de &os;.</para> + + <para>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 liberación de versiones de + &os;.</para> + </sect1> + + <sect1 id="future-goals"> + <title>Calendario de releases de aquí en adelante</title> + + <para>Estos son los objetivos actuales del calendario del + Proyecto:</para> + + <itemizedlist> + <listitem> + <para>Sacar uan release mayor cada 18 meses</para> + </listitem> + + <listitem> + <para>Sacar una release menor cada 4 meses</para> + </listitem> + + <listitem> + <para>Ofrecer paquetes compilados para la release menor más + reciente de cada release mayor</para> + </listitem> + + <listitem> + <para>Ofrecer actualizaciones de seguridad y otras correcciones de + fallos críticos para las versiones menores más + recientes de cada versión mayor (que reciben el nombre + de <firstterm>ramas de seguridad</firstterm>).</para> + </listitem> + </itemizedlist> + + <para>Dado el gran número de combinaciones de versiones + instalables no es posible dar soporte a todas las releases. + Esto es, en parte, debido a la cantidad limitada de máquinas + de las que el Proyecto puede disponer, pero sobre todo a que + la cantidad de voluntarios disponibles es limitada y su tiempo + también.</para> + + <para>Si quiere leer más sobre esto visite</para> + + <variablelist> + <varlistentry> + <term><ulink url="&url.base;/releng/index.html#schedule"></ulink></term> + <listitem> + <para>Calendario de ingeniería de releases</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><ulink url="&url.base;/security/security.html#supported-branches"></ulink></term> + <listitem> + <para>Calendario de ramas de seguridad</para> + </listitem> + </varlistentry> + </variablelist> + + <para>Estos documentos profundizan en los porqués de las + decisiones tomadas sobre las ramas soportadas y el ciclo de vida + de cada rama.</para> + </sect1> + + <sect1 id="decision-points"> + <title>¿Cómo afectan estos factores a su decisión?</title> + + <para>Los principales factores que influyen en su decisión de + qué versión instalar son, entre otros:</para> + + <itemizedlist> + <listitem> + <para>¿Qué grado de estabilidad necesita su + sistema?</para> + </listitem> + + <listitem> + <para>¿Cuántos trabajo quiere dedicar a la + actualización?</para> + </listitem> + + <listitem> + <para>¿Durante cuánto tiempo va a usar una + versión dada entre una actualización y la + que venga más adelante?</para> + </listitem> + + <listitem> + <para>¿Cuánta importancia le da a la seguridad de su + sistema?</para> + </listitem> + + <listitem> + <para>¿Instalará desde código fuente o + binarios?</para> + </listitem> + + <listitem> + <para>¿Va a participar en el desarrollo de &os;?</para> + </listitem> + </itemizedlist> + + <para>Aquí hay unas normas para ayudarle a tomar una + decisión:</para> + + <itemizedlist> + <listitem> + <para>Si sus necesidades son a corto plazo y quiere disfrutar del + más alto grado posible de estabilidad (y no puede + dedicar muchos recursos a la actualización) probablemente + lo mejor sea instalar la release <literal>STABLE</literal> + más reciente y dejarla como está. Según + sean sus requisitos de seguridad puede o no aplicar los + parches de seguridad que vayan apareciendo.</para> + </listitem> + + <listitem> + <para>Si sus necesidades son a corto plazo y las nuevas + características o la seguridad son muy + importantes para usted (y está dispuesto a dedicar + tiempo a las actualizaciones) debería seguir la + rama <literal>STABLE</literal> más reciente.</para> + </listitem> + + <listitem> + <para>Si no va a poner la máquina en producción, + va a dedicar tiempo a depurar unos cuantos problemas y en + unos cuantos meses va a salir una nueva versión mayor, + puede instalar esa rama y ayudar al Proyecto haciendo pruebas + para hacer el sistema más estable y disponer de la + mejor release posible a medio y largo plazo.</para> + </listitem> + + <listitem> + <para>Sólamente si quiere instalar desde código + 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 + <literal>HEAD</literal>.</para> + </listitem> + </itemizedlist> + </sect1> + + <sect1 id="conclusion"> + <title>Conclusión</title> + + <para>Esperamos que este artículo haya servido de ayuda + para que comprender el modelo de desarrollo de &os; y + pueda decidir qué versión se ajusta más a sus + necesidades.</para> + </sect1> +</article> |