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

• Добавьте поддержку новой платформы, то есть добавьте gradle-%new%.properties со всеми необходимыми свойствами и скомпилируйте. Возможно, потребуется извлечь некоторый код в специфичные для платформы исходные наборы, чтобы плагин компилировался с каждой поддерживаемой платформой. См. раздел «Советы и рекомендации» для наиболее распространённых примеров того, как это сделать.

• Исправьте тесты.

• Обновите путь к журналу в конфигурациях запуска, таких как runIDEA и runCLion. Для конфигурации runIDEA требуется:

  • удалить элемент idea-%old%.log;
  • добавить элемент idea-%new%.log с путём $PROJECT_DIR$/plugin/build/idea-sandbox-%new%/system/log/idea.log.

• Обновите рабочие процессы CI, чтобы использовать новую версию платформы вместо старой. Обычно требуется просто обновить список platform-version во всех рабочих процессах, где мы собираем плагин. На момент написания это check.yml, rust-nightly.yml и rust-release.yml.

• Исправить комментарии BACKCOMPAT: %old%.

Советы и рекомендации

Неисчерпывающий список советов, как можно адаптировать свой код для нескольких платформ:

• Если вам нужно выполнить конкретный код для каждой платформы в сценариях сборки Gradle (build.gradle.kts или settings.gradle.kts), просто используйте свойство platformVersion и условия if/when. Обратите внимание, что в build.gradle.kts значение этого свойства уже получено в переменной platformVersion.

• Если вам нужны разные источники для каждой платформы:

  • проверьте, действительно ли вам нужен специфичный код для каждой платформы. Часто существует устаревший способ выполнения необходимых действий. Если это ваш случай, не забудьте подавить предупреждение об устаревании и добавить комментарий // BACKCOMPAT: %current%, чтобы отметить этот код, и исправьте устаревание в будущем.
  • извлеките различный код в функцию и поместите его в файл compatUtils.kt в каждом специфичном для платформы наборе источников. Это обычно хорошо работает, когда вам нужно вызвать специфический публичный код, чтобы сделать то же самое на каждой платформе.
  • если код, который вам нужно вызвать, не является публичным (например, он использует некоторые защищённые методы родительского класса), используйте механизм наследования. Извлеките AwesomeClassBase из вашего AwesomeClass, наследуйте AwesomeClass от AwesomeClassBase, переместите AwesomeClassBase в специфичные для платформы наборы источников и переместите весь специфичный для платформы код в AwesomeClassBase как защищённые методы.
  • иногда сигнатуры некоторых методов могут быть указаны при эволюции платформы. Например, protected abstract void foo(Bar bar) может быть преобразовано в protected abstract void foo(Bar<? extends Baz> bar), и вы должны переопределить этот метод в своей реализации. Это вводит несовместимость источников (хотя и не нарушает бинарную совместимость). Самый простой способ заставить его компилироваться для каждой платформы — ввести специфичный для платформы typealias, например, typealias PlaformBar = Bar для текущей платформы и typealias PlaformBar = Bar для новой, и использовать его в сигнатуре переопределённого метода. Также этот подход хорошо работает, когда какой-то класс, от которого вы зависите, был перемещён в другой пакет.
  • Если создание специфичного для платформы набора источников слишком сложно для вашего случая, есть способ выбрать специфичный код во время выполнения. Просто создайте соответствующее условие, используя com.intellij.openapi.application.ApplicationInfo.getBuild. Обычно это выглядит так:

val BUILD_%new% = BuildNumber.fromString("%new%")!!
if (ApplicationInfo.getInstance().build < BUILD_%new%) {
// код для текущей платформы
} else {
// код для новой платформы
}

Конечно, код должен быть совместим со всеми поддерживаемыми платформами, чтобы использовать этот подход. * Иногда вы хотите временно отключить некоторые тесты, чтобы выяснить, почему они не работают позже. Самый простой способ сделать это — пометить их аннотацией org.rust.IgnoreInPlatform. Под Худ, он использует предыдущий подход с ApplicationInfo.

• Если вам нужно зарегистрировать различные элементы в %xml_name%.xml для каждой платформы:

  1. Создайте platform-%xml_name%.xml в %module_name%/src/%current%/main/resources/META-INF и %module_name%/src/%new%/main/resources/META-INF.

  2. Поместите определения, специфичные для платформы, в эти файлы XML.

  3. Включите специфичный для платформы XML в %module_name%/src/main/resources/META-INF/%xml_name%.xml, то есть добавьте следующий код:

       <idea-plugin xmlns:xi="http://www.w3.org/2001/XInclude">
           <xi:include href="/META-INF/platform-%xml_name%.xml" xpointer="xpointer(/idea-plugin/*)"/>
       </idea-plugin>  

При поддержке новой версии IDE мы должны проверять все компоненты пользовательского интерфейса вручную, поскольку у нас пока нет тестов пользовательского интерфейса. Это особенно важно, если это крупное обновление IDE, так как крупные обновления платформы могут внести множество изменений.

Общие места

• Новый проект на Rust.
• Импорт проекта на Rust.
• Настройки Rust (в Языки и фреймворки).
• Панель инструментов Cargo.
• Конфигурация запуска.
• Параметры отладчика (в Сборка, выполнение, развёртывание > Отладчик > Представления данных > Rust, только CLion).

Специфические места

• Уведомления (см. MissingToolchainNotificationProvider).
• Действие «Выполнить команду Cargo».
• Рефакторинг «Реализовать члены».
• Рефакторинг «Ввести переменную».
• Рефакторинг «Извлечь функцию».
• Быстрое исправление и параметры «Автоимпорт».
• Варианты проверки «Неразрешённая ссылка».

Выпуски

Ночные и бета-версии выпускаются автоматически рабочими процессами GitHub. Стабильная версия обычно выпускается каждые две недели. За неделю до выпуска мы создаём ветку выпуска с именем release-%release_version% из ветки master. Значение release_version совпадает со значением соответствующей вехи. Ветви выпуска используются для создания сборок бета и стабильного плагина.

Большинство действий по выпуску можно выполнить автоматически через рабочий процесс GitHub. Вы можете запустить их из интерфейса GitHub (GitHub blog). Просто откройте вкладку «Действие», выберите необходимый рабочий процесс и запустите его с помощью кнопки «Запустить рабочий процесс».

В качестве альтернативы существует скрипт scripts/release-actions.py для запуска событий из вашей консоли. Синтаксис: python release-actions.py release_command --token github_token. Также вы можете предоставить переменную среды IR_GITHUB_TOKEN, чтобы указать токен GitHub. Это позволяет опустить опцию --token.

См. инструкцию, как создать личный токен GitHub. Обратите внимание, что он должен иметь область действия repo.

Обратите внимание, мы используем pipenv для управления версией Python, зависимостями и виртуальной средой. См. инструкции, как установить его. Чтобы запустить любую команду, просто выполните следующее:

cd scripts
pipenv install # для установки зависимостей
pipenv run python release-actions.py release_command --token github_token # для запуска скрипта в виртуальной среде

Доступные команды:

• release-branch — создаёт новую ветку выпуска release-%release_version% из master, где %release_version% совпадает со свойством patchVersion в gradle.properties. После этого она увеличивает patchVersion на единицу, фиксирует изменения и отправляет их в мастер. Обратите внимание, соответствующий рабочий процесс запускается по расписанию для создания ветки выпуска за неделю до релиза, поэтому обычно вам не нужно запускать его вручную.
• nightly-release — собирает плагин из ветки master и публикует его в канале nightly на [Marketplace]. Обратите внимание, соответствующий рабочий процесс запускается по расписанию, поэтому обычно вам не нужно запускать его вручную.
• beta-release — собирает плагин из ветки выпуска и публикует его в канале beta на [Marketplace]. Обратите внимание, соответствующий рабочий процесс запускается по расписанию, поэтому обычно вам не нужно запускать его вручную.
• stable-release — обновляет ссылку на журнал изменений в plugin/src/main/resources/META-INF/plugin.xml, фиксирует изменения, Отправляет изменения в ветку master и выбирает соответствующие изменения для ветки release. После этого плагин собирается из ветки release и публикуется в канал stable на [Marketplace].

Обратите внимание, что каждая команда может иметь дополнительные опции. Чтобы получить актуальный список опций, добавьте опцию --help.

Информация о выпуске находится на сайте intellij-rust.github.io. Чтобы написать информацию о выпуске, запустите ./changelog.py. Он просматривает все запросы на вытягивание (pull requests) из соответствующего этапа и создаёт шаблон с информацией по умолчанию о слитых PR в каталоге _posts. Исходный вариант каждого поста зависит от специальных тегов, которыми могут быть помечены PR. На данный момент changelog.py поддерживает теги feature, performance, fix и internal. Обратите внимание: PR можно пометить любым подмножеством этих тегов.

Преобразуйте сгенерированный текст в удобный для пользователя формат, добавьте необходимые ссылки/гифки. Не забудьте упомянуть каждого участника с помощью синтаксиса by [@username].