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

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