Нужно ли менять версию плагина, если вы просто обновляете атрибут «Проверено до»?

У меня есть несколько плагинов, размещенных на сервере WordPress.org SVN ... с выходом 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.