qual é a maneira correta de atualizar um plugin via tortoise svn para o repositório?


18

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!

existem muitas perguntas sobre o svn aqui, mas elas só me confundiram ainda mais: -z

de alguma forma eu consegui até agora, mas preciso saber o procedimento adequado para atualizar meu plug-in para a nova versão no que diz respeito a confirmar o tronco e criar um diretório de tags.

É isso que venho fazendo até agora.

  1. codifique as atualizações do plug-in no meu local até que eu esteja feliz com ele
  2. 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)
  3. confirmar o diretório do tronco
  4. 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?

além disso, sobre números de versão ...

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?

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)

outra pergunta,

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?


2
não há razão para ficar envergonhado, eu também tive problemas há um mês e você realmente foi muito além de eu :) @EAMann descreve todo o procedimento muito bem, incluindo capturas de tela, neste tópico: wordpress.stackexchange.com/questions/ 16951 /…

Respostas:


29

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.

  1. codifique as atualizações do plug-in no meu local até que eu esteja feliz com ele
  2. 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)
  3. confirmar o diretório do tronco
  4. 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:

  1. Codifique as atualizações do plug-in localmente até que você esteja satisfeito com ele
  2. Incremente a tag "stable" no seu readme.txtarquivo para corresponder ao novo número da versão
  3. Copie suas atualizações locais no /trunkdiretório da pasta do plug-in local
  4. Confirme o plug - in inteiro para salvar as alterações /trunkno repositório
  5. 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)
  6. 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/


2
Ótima resposta. Porém, uma pequena edição: quando você diz nunca alterar algo marcado, isso é quase verdade. Digamos que você digite um erro de digitação no seu leia-me, não há necessidade de fazer uma liberação de manutenção apenas para corrigi-la. Hoje estava conversando no # wordpress-meta com um dos principais desenvolvedores, que mencionou que não há problema em apenas editar sua versão marcada, desde que seja apenas o arquivo readme.txt . Nenhum outro. Em geral, sim, evite editar seus arquivos marcados.
Andy Mercer

Ótima resposta. A única coisa que gostaria de acrescentar é que, quando se trata de números de versão do plug-in, é uma boa idéia usar o Semantic Versioning, embora você não precise, facilita muito para os usuários saberem se o seu plug-in poderia interromper o site, se for necessário. uma alteração de versão MAJOR. Seja qual for o sistema que você escolheu para a versão do seu plugin, consista e lembre-se de atualizar o registro de alterações do leia-me.
Aron
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.