Мне стыдно сказать, что я немного не в курсе процедуры, используемой для обновления плагина с помощью tortoise svn, хотя мой плагин находится в репозитории годами и его загрузили более 300 000 раз!
Не будь SVN может быть сложным для многих людей ... так что давайте пройдемся по шагам ...
Это то, чем я занимаюсь до сих пор.
- закодируйте обновления плагина на моем локальном компьютере, пока я не буду им доволен
- скопировать все файлы из моей локальной папки плагинов в / trunk / (плагин и файл readme имеют обновленные номера версий)
- зафиксировать магистральный каталог
- щелкните правой кнопкой мыши каталог ствола и выберите «Создать ветку / тег» и установите его для копирования в папку в / tags / с именем, являющимся номером версии.
Это правильно и в правильном порядке? если нет, каков правильный путь?
Почти ...
Шаги, которые вы должны выполнить:
- Кодируйте плагин обновления локально, пока вы не будете довольны
- Увеличьте тег "stable" в вашем
readme.txtфайле, чтобы он соответствовал номеру новой версии
- Скопируйте свои локальные обновления в
/trunk каталог локальной папки плагинов
- Передайте весь плагин, чтобы сохранить изменения в
/trunk в хранилище
- Щелкните правой кнопкой мыши
/trunkи создайте новый тег, скопировав /tags/X.X.Xтуда, где xxx - та же версия в теге «stable» readme.txt(шаг 2).
- Передайте весь плагин, чтобы сохранить тег
по какой-то причине я перешел с версии 2.8.1 на 2.81.2 в своем последнем обновлении, означает ли это, что оно не будет отображаться как обновление, доступное на информационных панелях людей, имеющих версию 2.81.2, если я изменю номер следующей версии на 2,9?
Бинго. Если вы зафиксировали версию 2.81.2 в качестве обновления, и люди действительно загрузили это обновление, они не увидят 2.9, когда вы выпустите его.
Как WordPress определяет, какая версия является последней, и должен ли пользователь обновлять свою версию? это делает version_compare? это работает только с правильным форматом версии PHP не так ли? например. 2.9.2 считается более низкой версией, чем 2.81.2? (потому что, насколько я понимаю, version_compare начинается слева и сравнивается выше / ниже для каждой цифры, поэтому 9 будет считаться меньше 81)
Точно. При стандартном сравнении версий PHP версия 2.81.2 будет более новой, чем 2.9, потому что 81> 9.
Я рекомендую вам выпустить версию 3.0, а затем будьте очень осторожны при создании версий в будущем, чтобы избежать опечаток такого рода.
если я укажу глупую ошибку в коде, которая на самом деле не влияет на работу плагина, возможно, опечатку или дополнительное изображение. Что я могу отредактировать и сделать так, чтобы любые новые загрузки плагина содержали изменения?
я должен отредактировать ствол И папку с тегами и зафиксировать оба?
Если вам нужно внести незначительное изменение, считайте его техническим выпуском . Я обычно придерживаюсь такой схемы управления версиями:
2 . 1 . 3 . 5
major minor maint build
Сборка номеров, которые я использую только для внутреннего использования или для бета-версий ... вы почти никогда не будете увидите от меня номер сборки, если я электронной почте файл вручную (это способ распространения предварительных версий, который не нарушит обновления WordPress) ,
Если я обнаружу ошибку в живой версии, я сделаю быстрый патч и выпущу версию для технического обслуживания. Допустим, я выпустил версию 2.2 плагина, и кто-то заметил, что я забыл вызвать jQuery в режиме noConflict (). Я сделаю быстрый патч и сразу же выпущу 2.2.1.
Увеличение версии заставит WordPress распознать обновление и предоставить исправление всем, кто уже установил версию 2.2.
Чтобы выпустить версию для технического обслуживания, вы должны выполнить те же действия, что и при выпуске полной версии системы. Так что вносите изменения, увеличивайте версию readme.txt, фиксируйте/trunk , добавляйте теги и т. Д.
Но как только вы пометили что-то, вы никогда не измените это снова. Думайте о своей /tagsпапке как о замороженной во времени. Каждая версия в этой папке представляет собой снимок вашего плагина в определенный момент времени. Вы никогда не должны изменять какие-либо файлы в /tagsпапке напрямую.
Если вы думаете, что это может быть хорошей идеей, шлепните себя по затылку и вместо этого выпустите версию для обслуживания :-)
Как упоминал Пит, я ранее написал хороший набор пошаговых инструкций ... но сайт, похоже, потерял мои скриншоты. Вот еще одна версия того же пошагового руководства со скриншотами из «Черепахи», размещенного на моем собственном сайте: http://eamann.com/tech/how-to-publish-a-wordpress-plugin-subversion/