Чи потрібно обміняти версію плагіна, якщо ви лише оновлювали атрибут "Тестовано до"?

У мене є ряд плагінів, розміщених на сервері wordpress.org svn ... з випуском immenent 3.1, я хотів би оновити метадані "Тестовані до".

Функціональних змін у коді не буде, лише метадані.

Чи потрібно змінювати номер ревізії для такої дрібниці?

Я б збільшив номер версії лише в тому випадку, якщо користувачам потрібно буде знову завантажити плагін. Змінна "Перевірена до" не використовується при встановленні плагіна, лише коли люди хочуть його встановити або хочуть оновити. У такому випадку інформація все одно надходить з сервера, тому вам не потрібно змушувати нове завантаження вашого плагіна.

Звичайно, якщо ваш readme.txtв trunkкаталозі має Stable tagіндикатор, слід оновити readme.txtв правильному tagsпідкаталог, в іншому випадку він буде отримувати ігноруються. Немає проблем з оновленням файлу в tagsкаталозі та не створенням нової версії, для Subversion це звичайний каталог, як і всі інші, це лише умова використовувати його для тегів історичних випусків.

Я думаю, що інші відповіді докладно пояснили аргументи на користь натрапив на Tested up toатрибут, і я не бачу в них нічого поганого. Оскільки ніхто не згадав жодних причин не робити цього, я вважав, що буду грати захисника диявола;)

• Теги призначені і вважаються знімком програми в певний момент часу. Редагування тегу після факту порушує умови, на які люди покладаються, працюючи з кодом. У цьому конкретному випадку потенційні наслідки є незначними, якщо їх не існує, але багато людей вважають за краще виступити з пуристською позицією у подібних ситуаціях та залишати все зрозумілим на 100%. Ось чому деякі клієнти SVN видають попередження, коли користувач намагається здійснити зміни до тегу.
• Як потенційний користувач плагіну, якби я переглядав журнали SVN і помічав автора, який вносить зміни до тегів, я підозрюю, що, можливо, його обліковий запис був зламаний і хтось намагався ввести зловмисне програмне забезпечення в останню версію, або що автор не знав про те, як працює управління джерелами - і, за розширенням, може бути не дуже хорошим програмістом - що змусить мене вагатися з завантаженням плагіна.
• Ви втрачаєте деякі історичні дані. Наприклад, якщо ви хочете повернутися через рік і відстежити сумісність свого плагіна з основними версіями, ви не можете зробити точний аналіз, оскільки ваші дані були пошкоджені.
• Існує ще один механізм досягнення того ж результату. Репо дозволяє користувачам голосувати над тим, чи працює конкретна версія плагіна з певною версією ядра. Я особисто вірю цим даним більше, ніж твердження автора плагіна.
• Я підозрюю, що мотивація до подібних речей часто є власним егоїзмом та незахищеністю автора плагінів; вони хочуть переконатися, що їх плагін виглядає "успішним" і завантажується якнайбільше. Я дуже часто бачу подібну поведінку серед авторів плагінів і часто відчуваю спокусу і сам, але я вважаю, що це якась незріла і нездорова, тому намагаюся протистояти цьому.

Моя порада буде розслабитися і залишити теги в спокої. Просто додайте свій індивідуальний голос за "це працює" на сторінці репо, звичайно, після раунду тестування - і залиште це на цьому. Якщо ви насправді турбуєтеся про те, що ваш плагін виявляється активним, то витрачайте час на роботу над новими випусками з виправленнями помилок, покращенням безпеки / продуктивності / інтерфейсу користувача та новими корисними функціями; не витрачайте час на занепокоєння про те, що думають інші або скільки завантажень ваш плагін отримав минулого тижня.

Ну якщо ви тільки оновлюєте readme, то я не бачу причин збільшувати номер версії. Якщо ви просто використовуєте магістраль, ви можете швидко взяти на себе зобов’язання змінити це одне, і ніхто насправді не помітить, якщо ви використовуєте теги, я думаю, вам потрібно буде створити новий тег (не на 100% не так добре розбирається зі svn ).

Я думаю, що можна впевнено сказати, що це питання особистого вибору. Замість повного оновлення версії (наприклад, 1,0 до 2,0) ви можете розглянути можливість випуску 1.1.