¡Bienvenido! ¿Eres nuevo en Zcash?
The Zcash network is young, but evolving quickly! Sign up and we'll be in touch with monthly highlights on ecosystem growth, network development and how to get started with Zcash!

Idioma

Ciclo de Lanzamiento y Vida Útil

Nathan Wilcox | May 01, 2017

A partir de mayo, el esfuerzo de desarrollo de Zcash impulsará una nueva política de lanzamientos. Hay algunos puntos principales que los usuarios deberían tener en cuenta desde ahora:

Este es un programa de actualizaciones radical y si te resulta inadecuado, nos encantaría conocer tu opinión lo antes posible. Esto es lo que todo usuario necesita saber, el resto de este post describirá nuestros motivos y razones, además de algunos detalles sobre la actualización del protocolo.

Mejor Seguridad y Calidad

Desde nuestro lanzamiento hemos llevado a cabo un apretado programa de actualizaciones de una cada tres semanas. Hemos sacado todas las versiones dentro del plazo de un par de días en relación a la fecha planeada, con excepción de la última versión 1.0.9, pospuesta, y una versión hotfix, 1.0.8-1.

Nuestro nuevo proceso toma un poco más de tiempo entre lanzamientos. Utilizaremos este tiempo adicional para agregar pruebas de pre-lanzamiento y de testeo de paquetes más exhaustivas, tener una reunión retrospectiva para cada lanzamiento y comenzar la coordinación de cada lanzamiento para cada una de nuestras prioridades de hoja de ruta a más largo plazo.

Coordinación Más Clara

Un cambio esencial de esta nueva política es un ciclo de vida explícito de los lanzamientos, cuyos componentes más importantes son la fecha de lanzamiento y la fecha de obsolescencia, aproximadamente cuatro meses más tarde, el 4º tercer martes después del lanzamiento.

Para las versiones activas que aún no han alcanzado su fecha de obsolescencia, nos esforzamos al máximo para proporcionar correcciones de seguridad, seguimiento a informes de errores, evitar interrupciones en la red de producción y ayudar a los usuarios a actualizar a la última versión. Para las versiones obsoletas, la única ayuda que prometemos es la relacionada con la actualización a la última versión.

Con el fin de codificar este ciclo, tenemos incluso la intención de introducir una característica llamada auto-senescencia, comenzando con la versión 1.0.9, que hará que los nodos se salgan automáticamente cuando detecten que han alcanzado su fase de obsolescencia. Los usuarios tendrán siempre la opción de no utilizar esta característica, ya que (como se analiza más adelante) nuestro objetivo es permitir que los usuarios elijan por sí mismos, no coaccionarlos o controlarlos.

Una importante nota al margen: esta política se aplica completamente en el contexto de una única versión, por lo que un usuario no necesita saber nada acerca de nuestras versiones futuras ni nuestras nuevas políticas para esas versiones para comprender esta política para su propia instalación.

Autonomía del usuario: obsolescencia vs actualización automática

Consideramos que la elección del usuario es un valor primordial a proteger. Aunque puede sonar abstracto o excesivamente dramático, esto afecta directamente a nuestras opciones de diseño técnico y juega a favor de nuestra elección de un enfoque de obsolescencia, en lugar de un enfoque de actualización automática.

La actualización automática de las aplicaciones se ha generalizado, debido a sus numerosas ventajas. Una de las ventajas más importantes es la garantía de que el software antiguo es poco común, de modo que las vulnerabilidades y los aspectos técnicos desactualizados se eliminan de la red, lo que hace que el conjunto sea más seguro.

Por otro lado, la mayoría de los usuarios confían en un comportamiento predeterminado, y una actualización automática por defecto los coloca de facto bajo la influencia de un único grupo de desarrolladores de aplicaciones. La mayoría de la gente cree que esto está bien, y aunque a menudo sea el caso, creemos que estamos viendo un cambio profundo en las decisiones de facto, debido a este tipo de desarrollos tecnológicos.

Nosotros preferimos la obsolescencia en lugar de la actualización automática, donde los usuarios deben ellos mismos elegir actualizar a nuestras nuevas versiones o a versiones alternativas de otras personas. Creemos que esto todavía brinda la ventaja sistémica de quitar el viejo software, aunque todos los usuarios deben explícitamente optar por cada actualización, y cada ocasión es una oportunidad de educarse y de decidir un diverso sino.

¿Por qué la obsolescencia es mejor para Zcash?

Debido a que los usuarios y nuestra comunidad de desarrollo tienen este acuerdo, podemos comenzar a confiar en este calendario para actualizaciones de protocolos, ajustes de seguridad, mejoras de usabilidad y eliminación de retrasos técnicos.

Una vez que esta política se ponga en práctica a partir de nuestra versión 1.0.9 en mayo, estaremos en camino de comenzar la actualización del protocolo al conjunto de características de Sapling.

También podremos implementar mejoras de usabilidad, como la divulgación de pagos y en unos cuantos meses sabremos que el soporte para esas mejoras debería estar generalizado, y por lo tanto todas las billeteras y vendedores se beneficiarán de una amplia consistencia en todo el ecosistema.

Hice hincapié en "debería estar" porque los usuarios siempre pueden rechazar nuestra política de obsolescencia mediante la edición de su configuración local o la instalación de implementaciones alternativas. En ese caso, tendremos una señal clara de la comunidad de usuarios sobre sus reservas con nuestra dirección, por lo que este es uno de los mecanismos clave para mejorar nuestra gobernanza.

Nos Encantaría Conocer Tu Opinión

Comunícate con nosotros si tienes algún comentario sobre esta nueva política de lanzamientos. Puedes encontrarnos en el chat de la comunidad o, si lo prefieres, comunícate directamente por email.

[1]Todavía estamos determinando cuándo y cómo discontinuar las versiones anteriores a 1.0.9.

zcash, releases, users, software, consensus, forks | Ver todos los tags