docs(specs,db-guide): лестница версий формата 2.17-2.18-2.19-2.20

Спеки утверждали, что за 2.17 (8.3.20-8.3.24) сразу идёт 2.20 (8.3.27+),
и приписывали версии 2.20 всю дельту. Промежуточные версии существуют:
8.3.25 пишет 2.18, 8.3.26 - 2.19.

Атрибуция изменений исправлена по замеру одной конфигурации, выгруженной
четырьмя платформами: TypeReductionMode и TextToSpeech - 2.18, отказ ролей
писать право, равное setForNewObjects, - 2.19, LineNumberLength - 2.20.

Два утверждения о «дельте 2.20» в 1c-configuration-spec § 7 были ошибочны и
удалены. Сжатая шапка xmlns оказалась артефактом стороннего сериализатора в
эталонном дампе, а не форматом: платформа во всех версиях пишет полную шапку.
Стиль пустых элементов признаком версии не является - он различается и между
дампами одной версии.

Добавлено: ConfigurationExtensionCompatibilityMode платформа при выгрузке
подставляет свой собственный даже при неизменной конфигурации; три свойства
форм из 2.18 - изменение дефолта эмиссии, а не новые свойства (8.3.24
принимает их и сохраняет при роундтрипе, в отличие от TypeReductionMode).

В db-guide зафиксировано побайтовое совпадение выгрузок конфигуратором и
ibcmd - с оговоркой, что на разбор EPF/ERF это не переносится: там результат
определяется базой разбора, а не движком.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Nick Shirokov
2026-08-01 17:38:13 +03:00
co-authored by Claude Opus 5
parent 2e5289a88f
commit b92aad519c
9 changed files with 64 additions and 35 deletions
+10
View File
@@ -118,6 +118,16 @@ Claude вызовет `/db-run dev`.
и со всеми расширениями), `db-load-cf`/`db-dump-cf`, `db-load-dt`/`db-dump-dt`, `db-update`,
`db-load-git`, `epf-build`/`epf-dump`, `erf-build`/`erf-dump`.
При выгрузке **конфигурации** выбор движка на результат не влияет: выгрузка одной и той же базы
конфигуратором и `ibcmd` совпадает **побайтно** (проверено на полной выгрузке типовой конфигурации —
91807 файлов из 91807). Дампы конфигурации, снятые разными движками, сравнимы напрямую.
Это НЕ распространяется на разбор внешних обработок и отчётов (`epf-dump`/`erf-dump`): там результат
определяется не движком, а **базой, в которой идёт разбор**. Если ссылочные типы реквизитов в этой
базе не разрешаются (в конфигурации нет соответствующих объектов), в исходники попадают
идентификаторы вместо имени типа. Поэтому для разбора нужна база с матч-конфигурацией — и при
работе через `ibcmd` за этим надо следить отдельно, чтобы разбор не ушёл в пустую или чужую базу.
Ограничения:
- только **файловые** базы (для серверных используйте конфигуратор);
- если запрошен режим, который `ibcmd` не поддерживает (например, выгрузка в «плоском» формате),