Comment gérer la version du plugin lors de la mise à jour à l'aide de Tortoise SVN et du référentiel de plugins worpdress.org?
Récemment, j'ai essayé de mettre à jour mon plug-in sur le serveur WP. La mise à jour du dossier de coffre s’est bien passée, mais lorsque j’ai créé un dossier avec une nouvelle version sous le dossier tags et que j’essayais de le télécharger, seuls les fichiers enfants immédiats de ce dossier ont été téléchargés avec succès et les sous-dossiers ne l’ont pas été.
Finalement, j'ai compris que le fichier svn info "pense" que ce sous-dossier existe déjà sur le serveur alors qu'il ne le fait pas. J'ai donc utilisé la fonction de suppression de Tortoise et à quelques reprises, puis je l'ai ajouté et cliquez sur commit. Finalement, après plus d’une heure d’essais et d’erreur, j’ai réussi.
C'était vraiment frustrant parce que je sais que des personnes ont déjà reçu une notification de mise à jour et que certaines d'entre elles ont peut-être été mises à jour et ont reçu un message d'erreur qui a bloqué leur administrateur!
Mes questions sont:
- Devrais-je passer à travailler avec la ligne de commande au lieu de Tortoise? sera-ce plus sûr?
- Existe-t-il un moyen de reporter la notification de mise à jour de version jusqu'à ce que je confirme d'une manière ou d'une autre que j'ai terminé le téléchargement de la nouvelle version?
Question 1: Devrais-je passer à l'utilisation de la ligne de commande au lieu de Tortoise? sera-t-il plus sûr?
Non, tortoise SVN fait tout ce que vous devez faire et ne nécessite pas d'apprendre chaque commande en ligne de commande. Je l'ai utilisé beaucoup de temps, et je n'ai jamais eu de problèmes qui y soient liés, les problèmes étaient liés à mon utilisation;)
BTW: Tortoise SVN contient le même code sous le capot que le client en ligne de commande, de sorte que les deux sont exactement le même genre de coffre-fort. Mais vous pouvez également télécharger SVN pour la ligne de commande et même utiliser les deux en parallèle. Mais ce n'est pas vraiment quelque chose d'utile pour vous, je suppose. Prenez juste Tortoise SVN car il est beaucoup plus facile à utiliser.
Je pense que vous avez manqué de svn-ajouter les sous-répertoires. Tant que vous ne les ajoutez pas, ils ne seront pas engagés. C'est juste qu'ils n'étaient pas sous contrôle de version, donc SVN ne savait pas que ceux-ci devaient être engagés.
Question 2: Existe-t-il un moyen de reporter la notification de mise à jour de version jusqu'à ce que je confirme d'une manière ou d'une autre que j'ai terminé? le téléchargement de la nouvelle version avec succès?
Normalement, il n’est pas nécessaire de le faire. Pour la toute première version, le package Zip est créé automatiquement par le site Web wordpress. Pour toute version supplémentaire, vous devez baliser une version avant de générer le nouveau plugin.Zip.
Donc, tant que vous ne le faites pas tag votre prochaine version, personne ne sera averti de la nouvelle version.
Question supplémentaire 1: Donc, en gros, je peux télécharger la nouvelle version sans incrémenter la version dans le fichier de plugin principal. et le fichier lisez-moi et seulement quand je vois que la mise à jour a réussi, je ne peux mettre à jour que ces 2 fichiers après avoir incrémenté la version.
C'est ce que vous pouvez faire aussi. En fin de compte, vous devez mettre à jour le fichier readme.txt et les en-têtes du fichier du plug-in, sans quoi cela ne sera pas convivial, ce qui pourrait créer une vue erronée.
Normalement, je modifie directement ces deux fichiers dans mon coffre de développement directement après avoir balisé la dernière version, donc pas à la fin. Cela fonctionne très bien pour moi. C'est donc tout le contraire de votre question.
Juste tag pour votre prochaine version et vous allez bien. Le balisage signalera au référentiel de plugins wordpress.org qu’une nouvelle version est disponible. Jusque-là, seule la version de développement est mise à jour après chaque commit, si je me souviens bien. Et ce n’est pas problématique car c’est la version de développement. Celles-ci ne sont normalement pas téléchargées et elles ne sont pas annoncées avec la fonctionnalité de mise à jour.
Cela devrait également répondre à votre autre question: les notifications de mise à jour ne sont pas envoyées, sauf si vous les taggez.
Question complémentaire 2: La création d'une branche concerne les versions principales, non?
Non, ce n'est pas lié. Vous pouvez également créer une version marquée avec une version mineure ou corrigée. Le principe suivant est commun:
MyPlugin version 1.0.0
Ceci est la première version majeure.
MyPlugin version 1.1.0
Ceci est une version parue dans la première version majeure.
MyPlugin version 1.1.1
Ceci est la première version de correction de bug pour la première version de votre première version majeure.
Ceci est commun. Le référentiel de plugins wordpress.org ne supporte pas très bien cette solution, il ne fait que compter, quelle que soit sa position.
Pour affiner cela, vous pouvez étiqueter (dans les en-têtes de plugin) votre plugin comme étant stable:
* Stable tag: 1.1
Donc, sur wordpress.org, vous pouvez avoir une version stable uniquement, mais à côté de cela, vous pouvez également disposer d'innombrables autres versions. Et vous pouvez (et devriez) les étiqueter aussi. Probablement à chaque fois que vous corrigez un bogue ou avez ajouté une fonctionnalité.
Donc, vous comptez normalement les numéros de version. Si vous créez une version bêta, vous pouvez l'ajouter après, ce que les utilisateurs comprennent généralement bien:
MyPlugin version 1.0.1-beta
Cela fonctionne aussi bien. Pour un exemple concret, vous pouvez jeter un coup d’œil sur la table en bas ob cette page de plugin sur ma page d’accueil .
C'est un plugin wordpress qui est également publié sur wordpress.org. La liste correspondante peut être trouvée ici: http://wordpress.org/extend/plugins/better-http-redirects/download/