Совместимость. В целом, мы нарушаем обратную совместимость только в основных выпусках и только по очень веской причине. Обычно мы сначала объявляем об устаревании функции за один или два выпуска до этого.

В целом, изменения/расширения языка требуют написания и утверждения EEP (Erlang Enhancement Proposal), прежде чем они могут быть включены в OTP. Основные изменения или новые функции в ERTS, Kernel или STDLIB потребуют EEP или, по крайней мере, обсуждения в списке рассылки.

Перед отправкой запроса на вытягивание

• Убедитесь, что существующие тестовые случаи не завершаются ошибкой. Необязательно запускать все тесты (это займёт много часов), но вы должны хотя бы запустить тесты для приложения, которое вы изменили.
• Убедитесь, что все статические проверки пройдены, вызвав ./otp_build check. Вызовите ./otp_build check --help, чтобы узнать подробности о том, что делает ./otp_build check.
• Убедитесь, что действия GitHub проходят. Если вы перейдёте на https://github.com/$YOUR_GITHUB_USER/otp/actions, вы можете включить сборки действий GitHub для своего форка otp.

См. руководства Тестирование и Разработка, чтобы узнать, как запускать тесты и использовать систему сборки Erlang/OTP.

Убедитесь, что ваша ветка содержит чистые коммиты:

• Не делайте первую строку сообщения коммита длиннее 72 символов. Не заканчивайте первую строку точкой.

• Следуйте рекомендациям по Написанию хороших сообщений коммитов.

• Не объединяйте maint или master в свою ветку. Используйте git rebase, если вам нужно разрешить конфликты слияния или включить последние изменения.

• Каждый коммит должен представлять логическое изменение, такое как добавленная функция или исправленная ошибка, а также включать соответствующие изменения в документацию и тесты.

• Каждый коммит должен компилироваться отдельно и проходить наиболее релевантные тестовые примеры. Это позволяет использовать мощную команду git bisect.

• Изменения в нескольких приложениях следует вносить отдельными коммитами, чтобы облегчить проверку кода, если только особые обстоятельства не мотивируют один коммит, например, не нарушать возможность чистой сборки.

• Проверьте наличие ненужных пробелов перед фиксацией с помощью git diff --check. Однако не исправляйте уже существующие ошибки пробелов в строках исходного кода, которые не были затронуты.

Проверьте свой стиль кодирования:

• Убедитесь, что ваши изменения соответствуют стилю кодирования и отступам кода вокруг ваших изменений.

• Не фиксируйте закомментированный код или файлы, которые больше не нужны. Удалите код или файлы.

• В большинстве кодов (Erlang и C) отступ составляет 4 шага. Настоятельно рекомендуется использовать только пробелы для отступов.

Настройка Emacs

Если вы используете Emacs, используйте режим Erlang и добавьте следующие строки в .emacs:

(setq-default indent-tabs-mode nil)
(setq c-basic-offset 4)

Если вы хотите изменить настройку только для режима Erlang, вы можете использовать хук, подобный этому:

(add-hook 'erlang-mode-hook 'my-erlang-hook)

(defun my-erlang-hook ()
  (setq indent-tabs-mode nil))

После того, как вы отправили запрос на вытягивание

• Следите за обсуждением после вашего запроса на вытягивание, отвечайте на вопросы, обсуждайте и реализуйте изменения, запрошенные рецензентами. Меньшие изменения следует объединить в связанные коммиты.

• Если ваш запрос на вытягивание вводит новые общедоступные функции, они должны быть помечены версией OTP, в которой они появятся, в теге since в документации функций. Поскольку это обычно ещё не определено во время слияния вашего PR, человек, назначенный для вашего запроса на вытягивание, должен дать вам внутренний номер заявки (например, OTP-12345), который будет использоваться в качестве заполнителя в соответствующих тегах since, например -doc #{ since => ~"OTP @OTP-12345@" }. Когда ваши новые функции будут выпущены с выпуском OTP, этот заполнитель будет заменён фактической версией OTP, что приведёт к чему-то вроде «OTP 26.0».

• Если вас попросят написать примечание к выпуску для вашего запроса на вытягивание, см. Написание примечаний к выпуску.