ATUALIZAÇÃO 03/07/2014: A partir de agora, jquery-latest.js
não está mais sendo atualizado. Do blog da jQuery :
Sabemos que http://code.jquery.com/jquery-latest.js é abusado por causa das estatísticas do CDN mostrando que é o arquivo mais popular. Isso não seria o caso se estivesse sendo usado apenas por desenvolvedores para fazer uma cópia local.
Decidimos parar de atualizar este arquivo, bem como a cópia minimizada, mantendo ambos os arquivos na versão 1.11.1 para sempre.
A equipe do Google CDN se juntou a nós nesse esforço para evitar quebras inadvertidas da web e não atualiza mais o arquivo em
http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.js . Esse arquivo também ficará bloqueado na versão 1.11.1.
A seguinte resposta, agora discutível, é preservada aqui por razões históricas.
Não faça isso. Sério, não.
Vincular às versões principais do jQuery funciona, mas é uma má ideia - novos recursos inteiros são adicionados e descontinuados a cada atualização decimal. Se você atualizar o jQuery automaticamente sem testar seu código COMPLETAMENTE , você arrisca uma surpresa inesperada se a API de algum método crítico mudar.
Aqui está o que você deve fazer: escreva seu código usando a versão mais recente do jQuery. Teste, depure e publique quando estiver pronto para produção.
Então, quando uma nova versão do jQuery for lançada, pergunte-se: Eu preciso dessa nova versão em meu código? Por exemplo, há alguma compatibilidade crítica de navegador que não existia antes ou isso irá acelerar meu código na maioria dos navegadores?
Se a resposta for "não", não se preocupe em atualizar seu código para a versão mais recente do jQuery. Fazer isso pode até adicionar NOVOS erros ao seu código que não existiam antes . Nenhum desenvolvedor responsável incluiria automaticamente um novo código de outro site sem testá-lo completamente.
Simplesmente não há um bom motivo para SEMPRE usar a versão mais recente do jQuery. As versões antigas ainda estão disponíveis nos CDNs e, se funcionarem para seus objetivos, por que se preocupar em substituí-las?
Um problema secundário, mas possivelmente mais importante, é o cache. Muitas pessoas criam links para jQuery em um CDN porque muitos outros sites o fazem, e seus usuários têm uma boa chance de já ter essa versão armazenada em cache.
O problema é que o armazenamento em cache só funciona se você fornecer um número de versão completo . Se você fornecer um número de versão parcial, o armazenamento em cache em um futuro distante não acontecerá - porque, se isso acontecer, alguns usuários obteriam diferentes versões secundárias do jQuery do mesmo URL. (Digamos que o link para 1,7 aponta para 1.7.1 um dia e 1.7.2 no dia seguinte. Como o navegador se certificará de que está recebendo a versão mais recente hoje? Resposta: sem armazenamento em cache.)
Na verdade, aqui está uma análise de várias opções e suas configurações de expiração ...
http://code.jquery.com/jquery-latest.min.js (sem cache)
http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js (1 hora)
http://ajax.googleapis.com/ajax/libs/jquery/1.7/jquery.min.js (1 hora)
http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js (1 ano)
Portanto, ao vincular ao jQuery dessa forma, você está, na verdade, eliminando um dos principais motivos para usar um CDN em primeiro lugar.
http://code.jquery.com/jquery-latest.min.js também pode não fornecer a versão que você espera. No momento em que este livro foi escrito, ele se vincula à versão mais recente do jQuery 1.x, embora o jQuery 2.x também tenha sido lançado. Isso ocorre porque o jQuery 1.x é compatível com navegadores mais antigos, incluindo IE 6/7/8, e o jQuery 2.x não é . Se você deseja a versão mais recente do jQuery 2.x, então (por enquanto) você precisa especificar isso explicitamente.
As duas versões têm a mesma API, portanto, não há diferença de percepção para navegadores compatíveis. No entanto, jQuery 1.x é um download maior que 2.x.