Je suis gêné de dire que je suis un peu ignorant de la procédure utilisée pour mettre à jour un plugin via tortoise svn même si mon plugin est sur le référentiel depuis des années et a fait plus de 300 000 téléchargements!
il y a beaucoup de questions sur svn ici, mais elles ne font que me confondre davantage: -z
en quelque sorte, j'ai réussi jusqu'à présent, mais j'ai besoin de connaître la procédure appropriée pour mettre à jour mon plugin vers la nouvelle version en ce qui concerne la validation du tronc et la création d'un répertoire de balises.
C'est ce que j'ai fait jusqu'à présent.
- coder les mises à jour du plugin sur mon local jusqu'à ce que je sois satisfait
- copier tous les fichiers du dossier de mon plugin local dans / trunk / (le plugin et le fichier readme ont des numéros de version mis à jour)
- valider le répertoire du tronc
- faites un clic droit sur le répertoire du tronc et choisissez de créer une branche / tag et de le configurer pour copier dans un dossier dans / tags / avec le nom étant le numéro de version
Est-ce correct et dans le bon ordre? sinon, quelle est la bonne façon?
aussi, sur les numéros de version ...
pour une raison quelconque, je suis passé de la version 2.8.1 à 2.81.2 lors de ma dernière mise à jour, cela signifie-t-il qu'il ne s'affichera pas comme une mise à jour disponible dans les tableaux de bord des personnes possédant la version 2.81.2 si je change le numéro de version suivant en 2.9?
comment wordpress détermine-t-il quelle est la dernière version et si l'utilisateur doit mettre à jour sa version? fait-il une version_compare? cela ne fonctionne qu'avec le bon format de version php n'est-ce pas? par exemple. 2.9.2 est considéré comme une version inférieure à 2.81.2? (car, si je comprends bien, version_compare commence à gauche et compare plus / moins pour chaque chiffre, donc 9 serait considéré comme inférieur à 81)
une autre question,
si je repère une erreur stupide dans le code qui n'affecte pas vraiment le fonctionnement du plugin, peut-être une faute de frappe ou une image supplémentaire. Que dois-je modifier et m'engager pour que les nouveaux téléchargements du plugin contiennent la modification?
dois-je modifier le tronc ET le dossier de balises et valider les deux?
la source
Réponses:
Ne le sois pas. SVN peut être délicat pour beaucoup de gens ... alors passons en revue les choses étape par étape ...
Presque ...
Les étapes que vous devriez être la suivante:
readme.txtfichier pour qu'elle corresponde au nouveau numéro de version/trunkrépertoire du dossier du plugin local/trunkréférentiel/trunket créez une nouvelle balise, en copiant/tags/X.X.Xoù xxx est la même version dans la balise "stable" dereadme.txt(étape 2)Bingo. Si vous avez validé la version 2.81.2 en tant que mise à jour et que les gens ont effectivement téléchargé cette mise à jour, ils ne verront pas 2.9 lorsque vous la publierez.
Exactement. Une comparaison de version PHP standard verra la version 2.81.2 comme étant une version plus récente que 2.9 car 81> 9.
Je vous recommande de publier une version 3.0 ensuite, puis soyez très prudent lors de la version à l'avenir pour éviter ce type de faute de frappe.
Si vous devez apporter une modification mineure, considérez-la comme une version de maintenance . Je suit généralement ce type de schéma de version:
Les numéros de build que j'utilise uniquement en interne ou pour les versions bêta ... vous ne verrez presque jamais de numéro de build de moi à moins que je ne vous envoie un fichier manuellement par e-mail (c'est ainsi que je peux distribuer des versions préliminaires qui ne casseront pas les mises à jour de WordPress) .
Si je remarque un bug dans une version live, je vais faire un patch rapide et publier une version de maintenance. Disons que j'ai sorti la version 2.2 d'un plugin et que quelqu'un remarque que j'ai oublié d'appeler jQuery en mode noConflict (). Je vais faire un patch rapide et publier immédiatement 2.2.1.
L'incrémentation dans la version forcera WordPress à reconnaître la mise à jour et à fournir le correctif à toute personne ayant déjà installé la version 2.2.
Pour publier une version de maintenance, vous devez suivre exactement les mêmes étapes que si vous publiez une version complète du système. Donc, apportez des modifications, incrémentez la version
readme.txt, validez/trunk, étiquetez, etc.Mais une fois que vous avez marqué quelque chose, vous ne le changez plus jamais. Considérez votre
/tagsdossier comme figé dans le temps. Chaque version de ce dossier est un instantané de votre plugin à un moment précis. Vous ne devez jamais modifier/tagsdirectement les fichiers du dossier.Si vous pensez que cela pourrait être une bonne idée, frappez-vous à l'arrière de la tête et sortez une version de maintenance à la place :-)
Comme Piet l'a mentionné, j'ai écrit un bon ensemble d'instructions étape par étape plus tôt ... mais le site semble avoir perdu mes captures d'écran. Voici une autre version du même guide étape par étape avec des captures d'écran de Tortoise hébergées sur mon propre site: http://eamann.com/tech/how-to-publish-a-wordpress-plugin-subversion/
la source