Поправки
Следуя правилам [положения о рабочем процессе], после того, как PSR был «принят», PSR означает не может измениться, обратная совместимость должна оставаться на уровне 100 %, и любая путаница, возникающая из-за первоначальная формулировка может быть уточнена с помощью опечаток.
Правила для опечаток описаны в [положении о рабочем процессе] и разрешают только несовместимые с предыдущими версиями уточнение, которое необходимо добавить в метадокумент. Иногда в PSR потребуются модификации. сам документ, и этот документ описывает эти случаи.
1. Прекращение поддержки и замена
Если выясняется, что PSR требует существенных обновлений или опечаток больше не может устранить путаницу, затем необходимо заменить PSR в соответствии с рабочим процессом, изложенным в [правиле рабочего процесса].
Первоначальный PSR может в какой-то момент устареть, как указано в [постановлении о голосовании].
После того, как голосование за прекращение поддержки PSR и замену его другим PSR прошло, устаревшая PSR должна быть помечены как таковые в исходном документе, а ссылка должна быть размещена в теле.
Например, следующий Markdown должен быть размещен в самом верху соответствующего стандартного файла в
официальный репозиторий PHP FIG GitHub fig-standards.
Устарело — по состоянию на 30 декабря 2014 года PSR-0 помечен как устаревший. PSR-4 теперь рекомендуется как альтернатива.
2. Зависимости
Поскольку ожидается, что документы будут заменены, а не изменены, зависимости от по возможности следует избегать других PSR. Например, следующее больше не разрешено:
- Пространства имен и классы ДОЛЖНЫ соответствовать PSR-0.
Вместо этого - если создающая ее рабочая группа считает зависимость необходимой - тогда следующее можно использовать пример:
- Пространства имен и классы ДОЛЖНЫ следовать PSR автозагрузки: [[PSR-0]].
Внешний набор квадратных скобок обозначает «список зависимостей», который представляет собой список PSR. которые считаются совместимой зависимостью.
Когда в «список зависимостей» добавляется больше PSR, тот же пример будет выглядеть так:
- Пространства имен и классы ДОЛЖНЫ следовать PSR автозагрузки: [[PSR-0], [PSR-4]].
Новые PSR могут быть добавлены в «список зависимостей», но старые PSR никогда не могут быть удалены, так как это приведет к поломке. обратная совместимость.
3. Приемлемые поправки
Помимо обновления «списка зависимостей», есть два других потенциально приемлемых сценария внесения поправок. которые не требуют своего специального голосования.
3.1. Аннотации
Если добавляется опечатка, которая считается достаточно важной тем, кто инициирует голосование по ошибке, аннотации могут быть размещены в строке нарушения или рядом с ней, чтобы читатели знали, что нужно просмотреть опечатки для дополнительную информацию со ссылкой, содержащей привязку к этому конкретному фрагменту опечаток.
- Что-то запутанное в том, куда идут скобки. [ср. ошибка]
Это будет сделано в рамках голосования по ошибкам, а не его собственного.
3.2. Форматирование и опечатки
Если форматирование по какой-либо причине нарушено, изменение форматирования не должно рассматриваться как изменить документ. Они могут быть объединены или отправлены секретарем без колебаний, если они ничего не меняйте ни в смысле, ни в синтаксисе.
Некоторые опечатки, такие тривиальные, как неуместная запятая, могут незначительно повлиять на смысл. Будьте особенно осторожны, чтобы не измените обратную совместимость и создайте голосование, если не уверены. Тут поможет здравый смысл.
Примеры:
- Таблицы HTML в настоящее время не работают на php-fig.org из-за используемого синтаксиса.
- Кто-то написал что-то неправильно, и никто не заметил этого в течение года.
- Проблемы с GitHub Markdown