Tenho vergonha de dizer que sou um pouco ignorante sobre o procedimento usado para atualizar um plugin via tortoise svn, mesmo que meu plugin esteja no repositório há anos e tenha mais de 300.000 downloads!
Não seja. O SVN pode ser complicado para muitas pessoas ... então vamos passo a passo as coisas ...
É isso que venho fazendo até agora.
- codifique as atualizações do plug-in no meu local até que eu esteja feliz com ele
- copiar todos os arquivos dentro da pasta do meu plug-in local para / trunk / (o plug-in e o arquivo leia-me possuem números de versão atualizados)
- confirmar o diretório do tronco
- clique com o botão direito do mouse no diretório do tronco e escolha criar branch / tag e configure-o para copiar para uma pasta em / tags / com o nome como número da versão
Isso está correto e na ordem certa? se não, qual é o caminho correto?
Quase ...
As etapas que você deve seguir:
- Codifique as atualizações do plug-in localmente até que você esteja satisfeito com ele
- Incremente a tag "stable" no seu
readme.txtarquivo para corresponder ao novo número da versão
- Copie suas atualizações locais no
/trunkdiretório da pasta do plug-in local
- Confirme o plug - in inteiro para salvar as alterações
/trunkno repositório
- Clique com o botão direito
/trunke crie uma nova tag, copiando para /tags/X.X.Xonde xxx é a mesma versão na tag "stable" de readme.txt(etapa 2)
- Confirme o plugin inteiro para salvar a tag
por alguma razão, fui da versão 2.8.1 para a 2.81.2 na minha última atualização, isso significa que ela não será exibida como uma atualização disponível nos painéis das pessoas que possuem a versão 2.81.2 se eu alterar o número da próxima versão para 2,9?
Bingo. Se você confirmou a versão 2.81.2 como uma atualização e as pessoas realmente fizeram o download dessa atualização, elas não verão a 2.9 quando você a lançar.
como o wordpress determina qual é a versão mais recente e se o usuário deve atualizar sua versão? ele faz um version_compare? que só funciona com o formato de versão php adequado, não é? por exemplo. 2.9.2 é considerada uma versão inferior à 2.81.2? (porque, pelo que entendi, version_compare começa à esquerda e compara mais alto / mais baixo para cada dígito, então 9 seria considerado menor que 81)
Exatamente. Uma comparação padrão da versão PHP verá a versão 2.81.2 como sendo uma versão mais recente que 2.9, porque 81> 9.
Eu recomendo que você libere uma versão 3.0 a seguir e tenha muito cuidado ao fazer versões no futuro para evitar esse tipo de erro de digitação.
se eu encontrar um erro bobo no código que realmente não afeta o funcionamento do plug-in, talvez um erro de digitação ou uma imagem adicional. O que edito e comprometo para fazer com que os novos downloads do plug-in contenham a alteração?
eu tenho que editar o tronco E a pasta de tags e confirmar ambos?
Se você precisar fazer uma pequena alteração, considere uma liberação de manutenção . Normalmente, sigo esse tipo de esquema de controle de versão:
2 . 1 . 3 . 5
major minor maint build
Números de compilação que eu sempre uso internamente ou para versões beta ... você quase nunca verá um número de compilação a menos que eu envie manualmente um arquivo para você (é como eu posso distribuir versões de pré-lançamento que não quebram as atualizações do WordPress) .
Se eu detectar um bug em uma versão ao vivo, farei um patch rápido e lançarei uma versão de manutenção. Digamos que eu tenha lançado a versão 2.2 de um plug-in e alguém note que eu esqueci de chamar o jQuery no modo noConflict (). Vou fazer um patch rápido e liberar imediatamente 2.2.1.
O incremento na versão forçará o WordPress a reconhecer a atualização e fornecer a correção para quem já instalou a versão 2.2.
Para liberar uma versão de manutenção, você precisa seguir exatamente as mesmas etapas como se estivesse lançando uma versão completa do sistema. Portanto, faça alterações, aumente a versão readme.txt, confirme /trunk, marque etc.
Mas depois de marcar algo, você nunca mais o altera. Pense na sua /tagspasta como congelada no tempo. Cada versão dessa pasta é um instantâneo do seu plug-in em um momento específico. Você nunca deve alterar nenhum arquivo /tagsdiretamente na pasta.
Se você acha que pode ser uma boa ideia, dê um tapa na parte de trás da cabeça e libere uma versão de manutenção :-)
Como Piet mencionou, escrevi um bom conjunto de instruções passo a passo anteriormente ... mas o site parece ter perdido minhas capturas de tela. Aqui está outra versão do mesmo guia passo a passo com capturas de tela do Tortoise hospedadas em meu próprio site: http://eamann.com/tech/how-to-publish-a-wordpress-plugin-subversion/