Мені соромно сказати, що я трохи незрозумілий щодо процедури, яка використовується для оновлення плагіну через черепаху svn, хоча мій плагін уже багато років знаходиться у сховищі та мав понад 300 000 завантажень!
Не бути. SVN може бути складним для багатьох людей ... тому давайте переглянемо все покроково ...
Це те, що я робив до цих пір.
- кодуйте оновлення плагіну на моїй локальній, поки я не задоволений
- скопіюйте всі файли у моїй локальній папці плагінів у / trunk / (файл плагіна та readme оновили номери версій)
- ввести каталог магістралей
- клацніть правою кнопкою миші каталог магістралі та оберіть створити гілку / тег та встановіть її для копіювання у папку в / теги / з назвою номера версії
Це правильно і в правильному порядку? якщо ні, то як правильно?
Майже ...
Кроки, які ви повинні виконувати:
- Кодуйте оновлення плагіна локально, поки не будете задоволені цим
- Збільште тег "стабільний" у вашому
readme.txtфайлі, щоб відповідати номеру нової версії
- Скопіюйте свої локальні оновлення в
/trunkкаталог папки локальних плагінів
- Введіть весь плагін, щоб зберегти зміни до
/trunkсховища
- Клацніть правою кнопкою миші
/trunkта створіть новий тег, скопіювавши /tags/X.X.Xтуди, де xxx - та сама версія у тезі "стабільний" 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? (тому що, як я розумію, версія_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папці безпосередньо.
Якщо ви думаєте, що це може бути гарною ідеєю, поплескуйте себе по потилиці та випустіть натомість версію технічного обслуговування :-)
Як згадував Піет, я раніше написав гарний набір покрокових інструкцій ... але сайт, здається, втратив свої скріншоти. Ось ще одна версія цього ж покрокового керівництва зі скріншотами з Tortoise, розміщеним на моєму власному сайті: http://eamann.com/tech/how-to-publish-a-wordpress-plugin-subversion/