Colocamos muito tempo e esforço em tornar nossas
distribuições livres de erros. Pelo nosso conhecimento, não
liberamos uma única versão do MySSQL com qualquer erro
conhecido
'fatal'.
Um erro fatal é algo que faz o MySQL falhar com o uso normal, traz respostas erradas para consultas normais ou tem um problema de segurança.
Nós temos documentados todos os problemas conhecidos, bugs e assuntos que são dependentes das decisões de projeto. See Secção 1.8.6, “Erros Conhecidos e Deficiências de Projetos no MySQL”.
Nosso objeto é corrigir tudo que é possível, mas sem correr o risco de tornarmos uma versão menos estável. Em certos casos, isto significa que podemos corrigir um problema na(s) versão(ões) de desenvolvimento, mas não o corrigirmos na versão estável (produção). Naturalmente, documentamos tais problemas para que o usuários esteja ciente.
Aqui está um descrição de como nosso processo de contrução funciona:
Monitoramos erros de nossa lista de suporte ao cliente, a lista de email externa do MySQL e o banco de dados de bugs em http://bugs.mysql.com/.
Todos os erros relatados em versões usadas são inseridos nio banco de dados de bugs.
Quando corrigimos um erro, sempre tentamos fazer um caso de teste para ele e incluí-lo em nosso sistema de teste para assegurar que o erro nunca retornará. (Cerca de 90% de todos os erros corrigidos têm um caso de teste.)
Também criamos casos de teste para todos os novos recursos adicionados ao MySQL.
Antes de começarmos a fazer uma nova distribuição do MySQL, asseguramos que todos os erros repetitíveis relatados para a versão do MySQL (3.23.x, 4.0.x, etc) estão corrigidos. Se algo for impossível de corrigir (devido a alguma decisão de projeto interno no MySQL), documentaremos isto no manual. See Secção 1.8.6, “Erros Conhecidos e Deficiências de Projetos no MySQL”.
Nós fazemos uma construção para todas as plataformas para as quais suportamos binários (mais de 15 plataformas) e executamos nosso pacote de teste e benchmarks para todas elas.
Não publicaremos um binário para uma plataforma na qual os testes do pacote de benchmarks falharam. Se for um erro geral na fonte, o corrigimos e fazemos as contruções mais os teste em todos os sistemas novamente.
Se nós, durante a o porcesso de construção e teste (que leva de 2 a 3 dias) recebermos um relatório sobre um erro fatal (por exemplo, um que cause um core dump), o corrigiremos e reiniciaremos o processo de construção).
Depois de publicarmos os binários em http://www.mysql.com/,
enviamos um email de anúncio nas listas de email
mysql
e announce
. See
Secção 1.7.1.1, “As Listas de Discussão do MySQL”. A mensagem de anúncio
contém uma lista de todas as alterações da distribuição
e qualquer problema conhecido com ela. (A seção 'problemas
conhecidos' na notas das distribuições só tem sido
necessária em algumas da distribuições.)
Para darmos acesso rapidamente aos nossos usuários dos últimos recursos do MySQL, fazemos uma nova distribuição do MySQL a cada 4-8 semanas. Instantâneos do código finte são contruídos diariamente e estão disponíveios em http://downloads.mysql.com/snapshots.php.
Se, depois da distribuição estar pronta, recebermos
qualquer relatório que houve (depois de tudo) qualquer
coisa criticamente errada com a construção em uma
plataforma específica, corrigiremo-na imediatamente e
liberaremos um nova distribuição 'a'
para aquela plataforma. Graças aos nosso grande base de
usuários, problemas são encontrados rapidamente.
Nosso registro para boas distribuições feitas é muito boa. Nas últimas 150 distribuições, tivemos que fazer uma nova contrução para menos de 10 distribuições (em 3 destes casos, o erro era uma biblioteca glibc com problema em uma de nossas máquinas que levamos um longo tempo para encontrar.
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.