os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

- Add new translation: version-guide.

Browse source 
Submitted by: gabor@
Approved by:  jesusr@ (mentor)
This commit is contained in:
J. Vicente Carrasco 2008-02-03 15:02:16 +00:00
parent 014222409f
commit 1056b7e3e0
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=31440
2 changed files with 461 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
es_ES.ISO8859-1/articles/version-guide/Makefile Normal file
View file

@ -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"

442
es_ES.ISO8859-1/articles/version-guide/article.sgml Normal file
View file

@ -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&iacute;a de release de paquetes de distribuidores exteriores</ulink>'>
-->
]>
<!-- The FreeBSD Spanish Documentation Project
Original Revision: r1.11 -->
<article>
<title>C&oacute;mo elegir la versi&oacute;n apropriada de &os;</title>
<articleinfo>
<authorgroup>
<author>
<surname>El Proyecto de Documentaci&oacute;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&oacute;n de &os;</holder>
</copyright>
<abstract>
<para>As&iacute; que ha decidido instalar &os;. &iexcl;Bienvenido!
el prop&oacute;sito de este documento es ayudarle seleccionar la
versi&oacute;n apropriada.</para>
&trans.es.gabor;
</abstract>
</articleinfo>
<sect1 id="background">
<title>Introducci&oacute;n</title>
<para>Antes de decidir cu&aacute;l de las versiones de &os; quiere
usar es importante que comprenda los conceptos relacionados con
el desarrollo y el proceso de Ingenier&iacute;a de Releases
(<literal>RE</literal>).</para>
<para>&os; se desarrolla gracias a un gran grupo de gente,
casi siempre voluntarios. El c&oacute;digo fuente del kernel, de las
utilidades y de las bibliotecas m&aacute;s
com&uacute;nes est&aacute;n en un <firstterm>sistema de
gesti&oacute;n de c&oacute;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&aacute; 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&uacute;mero mayor de release</firstterm> y un
<firstterm>n&uacute;mero menor de release</firstterm>.</para>
<itemizedlist>
<listitem>
<para>El prop&oacute;sito de una release mayor es incluir
nuevas funciones. Es inevitable que, al a&ntilde;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&oacute;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&oacute;digo como con los programas
ejecutables. Si se da la ocasi&oacute;n, se a&ntilde;aden nuevas
caracter&iacute;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&aacute;nea del &aacute;rbol de
c&oacute;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&iacute;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&oacute;digo bajo
<literal>RELENG_5_4_0_RELEASE</literal> no cambien,
los que est&aacute;n bajo <literal>RELENG_5_4</literal>
s&iacute;, 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&iacute;a de los
usuarios puedan usarla. Las ramas que necesitan m&aacute;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 &uacute;ltima palabra sobre esto. Por favor,
tenga muy en cuenta que el proyecto lo forman voluntarios y no
puede ofrecer ning&uacute;n tipo de garant&iacute;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&oacute;nico, software ofim&aacute;tico,
etc.) El proyecto en s&iacute; no desarrolla estos programas,
solamente el <quote>framework</quote> que permite que &eacute;stos
puedan instalarse; este <quote>framework</quote> recibe el
nombre de <firstterm>Colecci&oacute;n de Ports</firstterm>).
Se pueden instalar aplicaciones desde el c&oacute;digo fuente si su
licencia permite este tipo de redistribuci&oacute;n; es lo que en
&os; se llaman los <emphasis>ports</emphasis>)), o como software
compilado si est&aacute; 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&aacute;quinas dotadas de
multiproceso sim&eacute;trico (Symmetric MultiProcessing,
o SMP)</para>
</listitem>
<listitem>
<para>Mejoras del rendimiento gracias a la adopci&oacute;n
de una nueva estrategia de gesti&oacute;n de recursos en el
kernel</para>
</listitem>
<listitem>
<para>A&ntilde;adir numerosas arquitecturas de procesador</para>
</listitem>
<listitem>
<para>Introducci&oacute;n de un nuevo modelo de
<quote>threading</quote></para>
</listitem>
<listitem>
<para>Introducci&oacute;n de un nuevo
<quote>scheduler</quote></para>
</listitem>
<listitem>
<para>A&ntilde;adir soporte de nuevas tecnolog&iacute;as como
la gesti&oacute;n de energ&iacute;a (especialmente importante en
m&aacute;quinas port&aacute;tiles), y sobre todo</para>
</listitem>
<listitem>
<para>no declarar ninguna versi&oacute;n como
<literal>STABLE</literal> hasta que estas tareas no se
hubieran terminado</para>
</listitem>
</itemizedlist>
<para>Esto llev&oacute; al problema de que hab&iacute;a varios
a&ntilde;os de diferencia entre el momento en el que 4.X
se declar&oacute; <literal>STABLE</literal> y el momento en el que
5.X se lleg&oacute; a <literal>STABLE</literal>. Esta circunstancia
tuvo diversos efectos no deseados:</para>
<itemizedlist>
<listitem>
<para>El n&uacute;mero funciones cambiadas simult&aacute;neamente
hizo muy dif&iacute;cil aislar esos cambios para hacerlos
compatibles con las versiones anteriores a la creaci&oacute; de
la rama <literal>STABLE</literal>.</para>
</listitem>
<listitem>
<para>Eso signific&oacute; que los usuarios que necesitaban
imperiosamente una nueva funci&oacute;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&iacute;a sus
demandas.</para>
</listitem>
<listitem>
<para>En los casos en los que se consigui&oacute; la compatibilidad
con versiones anteriores los desarrolladores se encontraron con otro
problema al intentar adaptar ciertas caracter&iacute;sticas a una
versi&oacute;n que ellos mismos hac&iacute;a tiempo que no usaban
como su plataforma de desarrollo principal.</para>
</listitem>
<listitem>
<para>El retraso tambi&eacute;n provoc&oacute; que cuando 5.3 se
declar&oacute; nueva release <literal>STABLE</literal> la
cantidad acumulada de cambios hizo la actualizaci&oacute;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 &aacute;rbol principal
y que se integren solamente cuando no afecten a otros
procesos simult&aacute;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&aacute; listo a tiempo se incluir&aacute; desactivado
por omisi&oacute;n y ser&aacute; incluido en la siguiente
release.</para>
</listitem>
</itemizedlist>
<para>Al publicar grupos de cambios m&aacute;s peque&ntilde;os y
de una forma m&aacute;s habitual se intenta tambi&eacute;n dedicar
menos tiempo y esfuerzo aplicando nuevas caracter&iacute;sticas de
<literal>HEAD</literal> a a la &uacute;ltima versi&oacute;n
<literal>STABLE</literal> (y poder as&iacute; usar dichas
nuevas caracter&iacute;sticas en m&aacute;s de una versi&oacute;n
mayor); a&uacute;n m&aacute;s, al estar los cambios m&aacute;s
aislados el riesgo de provocar nuevos problemas de seguridad es
mucho menor.</para>
<para>Adem&aacute;s, el concentrarse en una fecha y no en la
consecuci&oacute;n de una caracter&iacute;stica lista para
integrarse en el sistema, es m&aacute;s f&aacute;cil planificar
para el futuro tanto para los usuarios como a los desarrolladores
de aplicaciones ajenas al proyecto y, c&oacute;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&oacute;n de versiones de
&os;.</para>
</sect1>
<sect1 id="future-goals">
<title>Calendario de releases de aqu&iacute; 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&aacute;s
reciente de cada release mayor</para>
</listitem>
<listitem>
<para>Ofrecer actualizaciones de seguridad y otras correcciones de
fallos cr&iacute;ticos para las versiones menores m&aacute;s
recientes de cada versi&oacute;n mayor (que reciben el nombre
de <firstterm>ramas de seguridad</firstterm>).</para>
</listitem>
</itemizedlist>
<para>Dado el gran n&uacute;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&aacute;quinas
de las que el Proyecto puede disponer, pero sobre todo a que
la cantidad de voluntarios disponibles es limitada y su tiempo
tambi&eacute;n.</para>
<para>Si quiere leer m&aacute;s sobre esto visite</para>
<variablelist>
<varlistentry>
<term><ulink url="&url.base;/releng/index.html#schedule"></ulink></term>
<listitem>
<para>Calendario de ingenier&iacute;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&eacute;s de las
decisiones tomadas sobre las ramas soportadas y el ciclo de vida
de cada rama.</para>
</sect1>
<sect1 id="decision-points">
<title>&iquest;C&oacute;mo afectan estos factores a su decisi&oacute;n?</title>
<para>Los principales factores que influyen en su decisi&oacute;n de
qu&eacute; versi&oacute;n instalar son, entre otros:</para>
<itemizedlist>
<listitem>
<para>&iquest;Qu&eacute; grado de estabilidad necesita su
sistema?</para>
</listitem>
<listitem>
<para>&iquest;Cu&aacute;ntos trabajo quiere dedicar a la
actualizaci&oacute;n?</para>
</listitem>
<listitem>
<para>&iquest;Durante cu&aacute;nto tiempo va a usar una
versi&oacute;n dada entre una actualizaci&oacute;n y la
que venga m&aacute;s adelante?</para>
</listitem>
<listitem>
<para>&iquest;Cu&aacute;nta importancia le da a la seguridad de su
sistema?</para>
</listitem>
<listitem>
<para>&iquest;Instalar&aacute; desde c&oacute;digo fuente o
binarios?</para>
</listitem>
<listitem>
<para>&iquest;Va a participar en el desarrollo de &os;?</para>
</listitem>
</itemizedlist>
<para>Aqu&iacute; hay unas normas para ayudarle a tomar una
decisi&oacute;n:</para>
<itemizedlist>
<listitem>
<para>Si sus necesidades son a corto plazo y quiere disfrutar del
m&aacute;s alto grado posible de estabilidad (y no puede
dedicar muchos recursos a la actualizaci&oacute;n) probablemente
lo mejor sea instalar la release <literal>STABLE</literal>
m&aacute;s reciente y dejarla como est&aacute;. Seg&uacute;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&iacute;sticas o la seguridad son muy
importantes para usted (y est&aacute; dispuesto a dedicar
tiempo a las actualizaciones) deber&iacute;a seguir la
rama <literal>STABLE</literal> m&aacute;s reciente.</para>
</listitem>
<listitem>
<para>Si no va a poner la m&aacute;quina en producci&oacute;n,
va a dedicar tiempo a depurar unos cuantos problemas y en
unos cuantos meses va a salir una nueva versi&oacute;n mayor,
puede instalar esa rama y ayudar al Proyecto haciendo pruebas
para hacer el sistema m&aacute;s estable y disponer de la
mejor release posible a medio y largo plazo.</para>
</listitem>
<listitem>
<para>S&oacute;lamente si quiere instalar desde c&oacute;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&oacute;n</title>
<para>Esperamos que este art&iacute;culo haya servido de ayuda
para que comprender el modelo de desarrollo de &os; y
pueda decidir qu&eacute; versi&oacute;n se ajusta m&aacute;s a sus
necesidades.</para>
</sect1>
</article>