Release Notes

Release Notes объясняют релизы с точки зрения эксплуатации: что нового, что может затронуть ваш код и как обновляться безопасно.

v1.0.8

Позиционирование релиза

1.0.8 — это шаг от «набора полезных API» к «платформенному каркасу» для плагинов.

Ключевая идея релиза: объединить инфраструктуру в единый runtime-контекст и усилить эксплуатационную зрелость.

Что добавлено и усилено

• NextLibContext как unified bootstrap.
• Расширенный Dynamic Database слой (relations/include/upsert/migrations).
• Операционные модули:
  • reload orchestration,
  • metrics/health/structured logs,
  • i18n сервис,
  • in-memory messaging,
  • validation,
  • quests.

Практическая ценность

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

Что нужно сделать после апдейта

1. Проверить bootstrap инициализацию через NextLibContext.
2. Проверить DB lifecycle (закрытие manager в onDisable).
3. Проверить GUI YAML keys и reload сценарий.
4. Проверить fallback локаль и переводы.
5. Включить базовые метрики и health checks.

Потенциальные риски

• stale конфиги/старые ключи GUI;
• отсутствие JDBC драйвера в runtime;
• неполный reload pipeline;
• пропуск smoke-проверки после обновления.

v1.0.7

Ключевое в релизе

Расширение фильтрации Dynamic Database через продвинутые query operators.

Почему это важно

• меньше raw SQL;
• более выразительная бизнес-логика;
• меньше риска ошибочных конкатенаций запросов.

Что проверять

• корректность where-условий по null;
• граничные случаи для IN/BETWEEN;
• поведение существующих репозиторных методов.

Рекомендованный runbook выката

1. Подготовить staging-сервер с копией конфигов.
2. Применить обновление и выполнить startup test.
3. Прогнать ключевые команды/GUI/БД сценарии.
4. Выполнить reload и проверить отчёт.
5. Проверить health/metrics через 10-15 минут нагрузки.
6. Деплой в production с мониторингом логов.

Рекомендованный rollback plan

• держать предыдущий стабильный jar;
• иметь backup/снимок БД;
• иметь feature toggle/безопасный режим для критичных модулей;
• иметь процедуру выключения проблемной фичи без полного даунтайма.

Сигналы успешного релиза

• нет новых критичных stacktrace на старте;
• GUI и команды работают ожидаемо;
• latency ключевых DB сценариев в пределах нормы;
• health checks показывают стабильный up.

Сигналы, что релиз проблемный

• рост db.errors или reload failures;
• резкий рост таймеров на hot-path;
• регулярные жалобы игроков на GUI/квесты;
• нестабильные локализации (ключи вместо текста).

Политика релизных заметок для команды

Для каждого релиза фиксировать:

1. Changed API.
2. Migration notes.
3. Known issues.
4. Validation checklist.
5. Rollback instructions.

Рекомендации по обслуживанию документации

Если в исходном репозитории появляются дополнительные release-файлы:

• добавляйте отдельные MDX страницы по релизам;
• сохраняйте ссылку из этой страницы;
• синхронизируйте migration notes с changelog.

Связанные разделы

• Changelog
• Roadmap
• Troubleshooting

Release Notes имеет смысл использовать как операционный документ перед каждым production-деплоем.