El proyecto Firebird pronto liberará la primera versión pública "Alfa" de Firebird 2.0. Esta nueva versión es una liberación mayor de Firebird con muchas características nuevas, mejoras y correcciones de errores (Ver las notas de la versión Alfa, para detalles). En términos del ámbito de cambios, el salto de esta versión es equivalente o mayor a la transición de la versión 1.0 a la 1.5.
Es conocido que nos preocupamos por la calidad, y que no se liberará la versión 2.0 definitiva hasta que cumpla con nuestros estrictos requisitos de aseguramiento de calidad. Esto tomó cerca de un año para la versión 1.5 antes de que estuviéramos satisfechos. pero esta vez estamos en una situación distinta. El proyecto Vulcan alcanzó el "hito de usabilidad general" con solo unos pocos cabos sueltos, y nos gustaría combinar ambas bases de código tan pronto como sea posible. Esta combinación deberá dar como resultado la versión 3.0 de Firebird con soporte completo de SMP, arquitectura unificada (ya no habrá versiones classic, superserver o embedded) y otras mejoras (Ver el resumen de Vulcan, para más detalles). Aparte de los claros beneficios para los usuarios de Firebird, esta combinación resultará en una arquitectura y una base de código más limpia y concisa, y completará nuestra transición del antiguo código procedimental de C, a un código de C++ completamente orientado a objetos. Esto abrirá puentes para que los desarrolladores diseñen e implementen características más complejas tales como espacios de nombres, tablas temporales y otras características más que han sido solicitadas. Pero no podemos enfocarnos completamente en la combinación de Firebird/Vulcan antes de que Firebird 2.0 sea liberado, y por ello nos gustaría acortar la fase de A.C. (Aseguramiento de calidad) tanto como sea posible, pero sin comprometer nuestros estrictos requerimientos para la versión final. Podemos hacer eso realizando nuestro proceso de A.C. de manera más efectiva. La efectividad del proceso de A.C. de Firebird depende de gran manera en la retroalimentación de los usuarios finales, por lo que naturalmente buscaremos empezar con un aseguramiento de calidad más efectivo. Hasta ahora, la retroalimentación de los usuarios era aleatoria y completamente en manos de los usuarios finales. Básicamente, liberábamos una versión, esperábamos la retroalimentación por algún tiempo y se solucionaban los errores reportados (junto con otros elementos que encontrábamos internamente durante el periodo). Si no se encontraban o reportaban elementos importantes desde la última versión de RC (candidato a liberación), esa versión se reempacaba como versión final. Por supuesto, hay también etapas alfa y beta que siguen este patrón también, pero difieren en que a los desarrolladores se les permite hacer cambios en el código. Aunque esta rutina ha trabajado de buena manera para nosotros en el pasado, tiene una desventaja importante: No podemos saber qué tanto se ha probado la versión en la vida real, tanto en escala como en funcionalidad. Podemos sólo suponer datos aproximados basados en el número de descargas, retroalimentación directa, etapas de desarrollo, etc., para estimar el "índice de calidad". También tenemos sólo un indicador con el cual trabajar: el tiempo. Es por ello el tiempo tan largo del ciclo de liberación. Para mejorar eso, nos gustaría iniciar un programa administrado de prueba en campo, comenzando con Firebird 2.0. Esta prueba de campo administrada NO reemplazará el escenario de prueba de campo (o pruebas internas), sino que deberá trabajar como un complemento para otras rutinas de aseguramiento de calidad que utilizamos. El objetivo de la prueba de campo administrada es obtener información precisa acerca de pruebas de campo (por ejemplo, cómo fue probada la versión de prueba y con cuáles resultados), de tal manera que podamos estimar mejor los resultados del proceso de aseguramiento de calidad, enfocados en abrir espacios en aseguramiento de calidad y de esta manera enfocar nuestros recursos de A.C. de manera más precisa, por lo que eventualmente podamos lograr confiabilidad en la calidad del código de manera más rápida. La participación en el campo de prueba administrado es muy simple. Debes registrarte por correo electrónico a: [b]pcisar (arroba) ibphoenix.cz[/b] Donde describirás cómo te gustaría probar nuestras versiones de prueba. Preferimos cualquier método de prueba que sea cercano al uso real. Esto significa que si tienes una aplicación que se ejecute con Firebird, puedes simplemente tomarla en una "prueba de manejo" con la nueva versión (de prueba) de Firebird en algún ambiente de prueba, preferiblmente con datos reales. Por supuesto, puedes seleccionar cualquier método de prueba que gustes, y puedes aún enfocarte en sólo un área en particular en la que estés más interesado (por ejemplo, rendimiento, respaldos/restauraciones, nuevas características, optimizador, etc.). Puedes también describir cuál tipo de Firebird (CS/SS/Embedded) y plataformas(s) deseas probar. Se te enviará una notificación cada vez que una nueva versión de prueba esté disponible, y esperaremos un reporte acerca de los resultados (tanto buenos como malos) de tus pruebas. Sabemos que tal compromiso no puede ser fácil de acometer, por lo que es posible que se salten pruebas de la versión de prueba de campo, o abandones el programa en cualquier punto, por lo que nosotros premiaremos a todos aquellos que nos ayuden. Hemos creado un premio que en este momento contiene una playera T/polo de Firebird en el color y la forma que desees -de parte de IBPhoenix-, pero estamos seguros de que tendremos más premios antes de la liberación de Firebird 2.0. Al finalizar el ciclo de liberación, premiaremos a los probadores más activos y a un probador seleccionado al azar. El programa de prueba de campo administrado está abierto a cualquier persona, en cualquier punto del ciclo de liberación (empezando desde el primer alfa hasta el último RC), pero aquellos que se registren antes tendrán más oportunidades de obtener un premio por su ayuda. Pavel Cisar División de A.C. del Proyecto Firebird Documento original en: http://www.firebirdsql.org/index.php?op=devel&sub=qa y en http://www.ibphoenix.com/main.nfs?a=ibphoenix&s=1110560445:163436&page=ibp_20_qa