Самая важная часть моего сообщения:
После обновления эти предупреждения об устаревании, как вы и сказали, превратятся в ошибки 
Да, к ним можно получить доступ через внедрённые свойства компонентов или импортировав модули Site и User из discourse/models/user и discourse/models/site.
Да, полезная альтернатива передаче их через хелперы в качестве параметров.
Для моего плагина, который я разрабатываю и запускаю через ./bin/ember-cli, мне не о чем беспокоиться, поскольку я использую ember-cli.
Но меня беспокоят десятки или даже сотни людей, которые узнают об этом слишком поздно — те, кто не различает JavaScript и CSS или плагин от компонента темы. Им не о чем волноваться, если только в компоненте темы нет JavaScript-кода.
Мне бы хотелось иметь простой тест, чтобы они могли понять, есть ли у них повод для беспокойства. Для таких людей я порекомендую запустить новый сервер, восстановить базу данных и проверить, не произойдёт ли сбой. Верно?
Или им лучше просто включить EMBER_CLI_PROD_ASSETS: 1, выполнить пересборку, и если что-то сломается — отключить эту настройку, а затем запустить новый сервер для исправления проблемы.
Думаю, можно выполнить запрос, чтобы проверить наличие theme_fields с типами html или js:
Это сработает, но настройка целого нового сервера кажется излишне трудозатратной. Вместо этого я рекомендую:
. . . Если только вы не потратили последний год на разработку инструмента, который делает «легким» развёртывание новых серверов? 
Так что произойдёт с теми, кто не обращает внимания на такие вещи: всё сломается, когда наступит срок перехода на Ember по умолчанию, а затем они смогут отключить эту переменную окружения ещё на месяц-два (и, вероятно, исправить проблему), прежде чем этот способ перестанет работать.
Я восстановил резервную копию на новом сайте с включённой темой Kanban, и возникают ошибки (я уже сообщил об этом в теме про Kanban). Я попробовал установить
EMBER_CLI_PROD_ASSETS: 0
но пересборки по-прежнему показывают:
Почему стоит делать это регулярно:
https://github.com/browserslist/browserslist#browsers-data-updating
что, как мне кажется, связано с ember-cli. Есть ли способ отключить это на новых сайтах?
Если я пересоберу старый сайт, получит ли он новый базовый образ и окажется ли невозможным отключение ember-cli?
Это опечатка в вашем сообщении здесь или опечатка в вашем yml? Должно быть EMBER_CLI_PROD_ASSETS: 0
Спасибо! Да, это опечатка, но в файле yml у меня всё верно. Я просто скопировал и вставил это правильно в первом сообщении.
Проверка в коде, похоже, не изменилась, но я не очень хорошо знаком с Ruby. Будет ли условное выражение с булевым значением ENV['EMBER_CLI_PROD_ASSETS'] использовать значение этого ключа или оно будет истинным, если ключ просто существует?
Если последнее, то решением может быть удаление EMBER_CLI_PROD_ASSETS из YAML-файла, а не установка его значения в 0.
Это не сработает, вам нужно удалить эту строку.
. . . подождите . . .
Ни одна из моих проблем не была связана с ember-cli, а с моей собственной неправильной конфигурацией, поскольку это была установка с двумя контейнерами, и web_only.yml не обновлялся при обновлении standalone.yml. Вот PR:
Ember CLI теперь является стандартом для всех установок Discourse. При следующем обновлении (либо через интерфейс /admin/upgrade, либо через команду ./launcher rebuild app) вы автоматически перейдёте на Ember CLI.
Мы уже используем Ember CLI в большинстве наших управляемых хостингов, поэтому не ожидаем серьёзных проблем. Однако, если вы заметите что-то необычное, пожалуйста, создайте тему здесь, на Meta, и мы проведём расследование.
Вчера я восстановил сайт, который не работал из-за ember CLI, и исправил проблему, убрав EMBER_CLI_PROD_ASSETS=1.
На раннем этапе я пробовал отключить ember CLI, установив EMBER_CLI_PROD_ASSETS=0, и, насколько я помню, ember_cli всё равно оставался включённым. Кто-то сказал мне, что отключить его, установив значение в 0, нельзя (это звучало нелогично, но, похоже, было правдой).
Это создаёт определённые трудности для тех, кто размещает сайты самостоятельно, особенно если у них старые темы и они никогда не смотрят в консоль JavaScript.
Это было верно, но я исправил логику в последнем коммите, чтобы =0 работал как ожидалось. Тем не менее, мы намерены полностью убрать «устаревшую» среду в течение нескольких недель, поэтому не используйте =0, если это не требуется на крайне короткий срок.
Мы добавили обратную совместимость для наиболее распространённых ошибок, которые мы наблюдали у наших хостинг-провайдеров. Например, в этом коммите несколько недель назад была добавлена обратная совместимость для Discourse.User и Discourse.SiteSettings. Этот коммит исправил некоторые проблемы для тем с нестандартными процессами инициализации.
Мы хотим сделать этот переход максимально плавным, поэтому, если вы столкнулись с ошибками за последнюю неделю или около того, пожалуйста, сообщите нам точное описание ошибки и код, который её вызвал.
О. Ура. Это имеет смысл. (Это работает так, как я всегда думал. И я не сумасшедший, что помню, как мне говорили, что это не работает так, как я предполагал. Это отличные новости!).
Мне очень трудно это выяснить (вероятно, из-за незнания). Когда я нажимаю на элемент, который, как я думаю, должен показать причину ошибки, я получаю код, который, по-видимому, предназначен для проверки устаревания, а не код, демонстрирующий саму ошибку. Я постараюсь прислать примеры в ближайшее время.
Если вам нужна помощь в решении проблемы, создайте тему в разделе Support и приложите скриншот ошибки — это будет хорошим началом. Тогда мы сможем помочь с отладкой. Вероятно, кто-то другой уже сталкивался с похожей ошибкой и сможет узнать симптомы. 
И теперь финальный шаг этой истории: устаревшая система сборки отключена. Все установки Discourse будут компилировать ресурсы с помощью Ember CLI.
Это изменение затронет только тех, кто намеренно установил EMBER_CLI_PROD_ASSETS=0 в своей конфигурации. В таком случае во время сборки будет выведено предупреждение, и будет использован Ember CLI.