release - sirve - programas para actualizar software de celulares android

¿Con qué frecuencia debe lanzar actualizaciones de software? (15)

Hace un momento, Jeff Atwood dijo lo siguiente en twitter :

Mira, me encantan las nuevas y rápidas versiones de software, pero la frecuencia de los lanzamientos de WordPress es simplemente ridícula.

Lo que me hace pensar, ¿con qué frecuencia debería lanzar actualizaciones de software?

¿Diario?
¿Semanal?
¿Mensual?
¿Anual?

¿Cuál es la mejor estrategia de lanzamiento?

Creo que si es posible , debería tener su actualización de software automáticamente cuando sea necesario, a fin de mantener todo el proceso de actualización tan fácil e invisible para el usuario como sea posible.

Siempre que sean requeridos. Tenga en cuenta que algunos usuarios se sienten más seguros al recibir actualizaciones regularmente, mientras que otros simplemente se molestan por tener una ventana emergente todos los días. "¡Hay 129 actualizaciones nuevas para instalar! ¡Haga clic aquí para esperar 20 minutos para descargar, luego otros 10 para instalarlos!" ... ves mi punto.

Sugeriré lo siguiente:

updateTime (en segundos): el tiempo promedio que tarda el usuario en realizar la actualización

releaseDelta (en días): el tiempo mínimo entre lanzamientos

releaseDelta = updateTime/((1/365)*(60*60*8))

Esta fórmula se basa en mi teoría de que un usuario debería tener que dedicar no más de 8 horas en un año determinado a la espera de actualizaciones de una aplicación.

Esto también permite una actualización frecuente siempre que las actualizaciones se realicen de manera transparente sin interrumpir al usuario final.

Creo que esto depende mucho de tu situación particular. Dicho esto, creo que un lanzamiento diario para cualquier aplicación comercial seria simplemente ridículo. Si está liberando todos los días, es probable que haya un problema grave a menos que se encuentre en una situación muy extraña en la que las reglas comerciales cambian constantemente o algo así.

Depende del enfoque del cliente para el control de la configuración.

Ellos tienen una elección, ya sabes. En última instancia, pueden elegir no usar su producto.

Si el cliente lo acepta a usted cambiando cosas todos los días, y no les importa, y no tiene un impacto en la capacitación ni en la administración de la configuración; tener actualizaciones automáticas

Los clientes con SOE (entornos operativos estándar) odian las actualizaciones.

Tenga en cuenta que algunos clientes no van a aceptar el software "llamando a casa". Querrán alojar sus propias actualizaciones. Su gente de TI tendrá que involucrarse. Esto es más trabajo para ellos.

Algunos clientes querrán / necesitarán hacer su propio control de calidad; depende del cliente y del tipo de software.

Si el cliente necesita hacer pruebas / trabajar para aceptar / implementar el software, libere algunos múltiplos de la duración del ciclo de prueba / implementación. A menos que los clientes estén de acuerdo con el despliegue y la prueba intercalados. Ahí es donde siempre están probando una nueva versión y la implementan.

Por ejemplo: 2 semanas para probar, liberar no más de cada 8 semanas.

En el software crítico de resultados, las pruebas de lanzamiento pueden demorar meses en llegar a un cliente. Están apostando su negocio por los resultados y son justificadamente cautos. Así que los lanzamientos son cada 6 meses más o menos.

En software de seguridad crítica, puede tomar MUCHOS meses. Anualmente o aproximadamente cada 18 meses no es infrecuente. Aún menos a menudo es bastante normal.

Diría que en el caso específico de WordPress, combinan "actualizaciones de seguridad" y "actualizaciones de funcionalidad" . Esto es malo.

Esto sería como tener que hacer una reinstalación en el lugar de Windows cada vez que se encuentra un error de seguridad, en lugar de simplemente descargar un pequeño parche cada semana.

WordPress necesita tener un mecanismo de parche de seguridad que sea simple, rápido y fácil para las actualizaciones de seguridad. Un proceso que está separado del flujo de actualización normal de las nuevas versiones.

Intento usar la siguiente, con suerte simple, pauta de dos partes:

Si requiere que el usuario descargue y / o instale algo, o cambie una base de código existente que ellos mantienen, entonces las versiones deben proporcionar un mérito significativo. Este es un lanzamiento que agrega nuevas funciones significativas, solucionó una cantidad importante de problemas o soluciona un número menor de problemas inmediatos y apremiantes.
Si no requiere que el usuario descargue y / o instale, se planearán las entregas, según lo dictado por la iteración. Si hay un producto liberable al final de la iteración, se implementará. La iteración contendrá las necesidades técnicas y comerciales según lo determinado antes del inicio de la iteración.

Entonces, para nosotros, cosas como aplicaciones de escritorio o servicios web generalmente caen bajo la primera regla, y cosas como nuestro sitio web caen bajo la segunda. Ejecutamos iteraciones de bastante buen tamaño, actualmente entre cuatro y seis semanas de tiempo de desarrollo, disminuyendo a dos o cuatro el próximo año. Esta fue nuestra "introducción" a un Scrum-hybrid.

Tenga en cuenta que un producto no siempre tiene que estar en desarrollo (o participar en una iteración). Es muy posible que un producto se quede obsoleto, hasta que se necesiten cambios si se aplica la primera regla.

La frecuencia de las versiones de Wordpress es tan frecuente porque se preocupan por la seguridad y lanzan actualizaciones que corrigen las vulnerabilidades conocidas lo más rápido que pueden. Las actualizaciones de funcionalidad para Wordpress ocurren con mucha menos frecuencia, en el rango de cada 4 a 6 meses, creo.

Creo que este es un buen modelo. Mantenga contentos a sus clientes lanzando nuevas funciones regularmente, pero si encuentra fallas de seguridad, libere las correcciones de inmediato.

Menos frecuentemente que las actualizaciones de iTunes.

No hay una respuesta correcta, realmente depende del producto.

Digo mensual como máximo. Semanalmente / diariamente es demasiado frecuente, a menos que, por supuesto, las actualizaciones de la aplicación se realicen de forma automática y transparente, por ejemplo, el sistema de actualización de Firefox.

No me opongo a que los errores de seguridad se solucionen tan pronto como se encuentren, aunque me gustaría que escribieran un código más sólido en primer lugar. Lo que objetaré (al menos en lo que respecta a Wordpress) son las versiones de mejora que podrían potencialmente impedir que los complementos ocurran demasiado rápido. ¿Cuánto tiempo pasó de 2.5 a 2.6? Y 2.7 también sale muy pronto.

Una actualización automática o semiautomática mitigaría parte de ese problema, pero solo si los escritores de complementos también se actualizan, o si separó las correcciones de seguridad de los cambios de funcionalidad para poder, por ejemplo, seguir con 2.5 pero estar actualizado con la seguridad parches hasta que estuve seguro de que todos los complementos que uso funcionan con 2.6 o 2.7 o (para ese momento) 4.0.

Para el área donde trabajo, los controles industriales, muy raramente. Por lo general, hacemos un gran lanzamiento muy 2 años. Versiones menores tal vez cada 3 a 6 meses. Los parches de errores son, por supuesto, una historia diferente, se publican según sea necesario. Incluso entonces, pocos clientes actualizarán los sistemas existentes. Por supuesto, en otros dominios, las actualizaciones son más aceptadas.

Puede liberarlos con la frecuencia que desee. Lo que frustra a los usuarios es no saber si necesitan su nueva versión o no. Esto significa que debe tener muy claro qué características nuevas ha implementado, los errores que ha solucionado y si ha solucionado algún problema de seguridad. Lo que es más importante, sus usuarios desean poder confiar en que, si instalan una nueva versión, nada se rompió.

Sin duda, cuando tienes nuevas características / correcciones de errores vale la pena liberar? ¿Por qué tenerlo en un horario?

Depende de la naturaleza de la actualización y la cantidad de intervención del usuario necesaria para lograrlo.

Si es un sitio web, puede actualizar todos los días, siempre y cuando no rompa nada.

Si se trata de una actualización de seguridad gratuita, siempre se agradece.

Una actualización gratuita de la corrección de errores, si debe ser instalada por el usuario, no debería ser más que cada par de meses.

Todo lo que debe pagarse no puede ser más frecuente que una vez al año, o las personas comenzarán a sentirse beneficiadas. Aún más para ciertas clases de software, como los sistemas operativos.