diff --git a/ChangeLog.md b/ChangeLog.md
index adc2db6a..9e0d507b 100644
--- a/ChangeLog.md
+++ b/ChangeLog.md
@@ -4,7 +4,7 @@ ChangeLog
 English version [by liar Google](https://libmdbx-dqdkfa-ru.translate.goog/md__change_log.html?_x_tr_sl=ru&_x_tr_tl=en)
 and [by Yandex](https://translated.turbopages.org/proxy_u/ru-en.en/https/libmdbx.dqdkfa.ru/md__change_log.html).
 
-## v0.14.1 в активной разработке без конкретизации даты выпуска
+## v0.14.1 выпуск запланирован в начале мая
 
 Первый выпуск в новом кусте/линейке версий с добавлением функционала, расширением API и внутренними переработками.
 
@@ -19,9 +19,62 @@ and [by Yandex](https://translated.turbopages.org/proxy_u/ru-en.en/https/libmdbx
  - [maxc0d3r](https://gitflic.ru/user/maxc0d3r) for bug reporting and testing.
  - [Алексею Костюку (aka Keller)](https://t.me/keller18306) за сообщения о проблеме копирования на NFS.
 
-
 Новое:
 
+ - Переработан код обновления GC и возврата страниц при фиксации транзакций.
+
+   Возникающая при этом задача алгоритмически сложна, так как список
+   возвращаемых страниц находится в рекурсивной зависимости от самой
+   процедуры возврата и связанных с этим операций, а прямые решения во
+   многих случаях приводят к многократному росту накладных расходов.
+   Поэтому исторически эта часть кода была запутанным наслоением «сдержек и
+   противовесов», что создавало препятствие для развития. В ходе этой
+   доработки, унаследованный из LMDB код связанный с обновлением GC, был
+   полностью заменен вместе со всеми базирующимися на нём заплатками.
+
+   Новая реализация использует контейнеры идентификаторы (aka RKL),
+   комбинирующие внутри списки элементов и непрерывные интервалы, что
+   позволяет предельно сократить накладные расходы и упросить реализацию
+   остальных алгоритмов. Основывается новая реализация на простом
+   прагматичном подходе «резервирования со взвешенным запасом». Для
+   подавляющего подмножества сценариев этого достаточно для однопроходного
+   обновления GC, с общей сложностью от `O(1)` для мелких транзакций, до
+   `O(log(N))` для огромных. При этом реализованный еще в 0.12.1 подход «Big
+   Foot» (дробление больших списков retired-страниц) полностью избавляет GC
+   от потребности в последовательностях смежных/соседствующих страниц и
+   одновременно позволяет работать новому коду обновления GC только по
+   самому простому и быстрому пути.
+
+   Тем не менее, при намеренном отключении «Big Foot», либо при работы с БД
+   от старых версий движка без «Big Foot», возможны сложные ситуации, когда
+   в GC могут огромные списки страниц, которые желательно дробить при
+   возвращении неиспользованных переработанных остатков. В таких сценариях
+   для возврата в GC требуется создавать больше записей чем было исходно
+   переработано, что может приводить к нехватке имеющихся/переработанных
+   идентификаторов. Тогда в игру вступает следующая часть нового кода,
+   поиск в GC «дыр» (неиспользуемых промежутков/интервалов в пространстве
+   ключей GC). Далее, если свободных идентификаторов (неиспользуемого
+   пространства ключей GC) будет недостаточно, что весьма вероятно в
+   некоторых сценариях, будет решаться задача родственная «укладке
+   рюкзака». В конечном итоге, неиспользованные переработанные страницы
+   будут возвращены в GC, с максимально равномерным
+   распределением/дроблением и использованием имеющихся последовательностей
+   смежных/соседствующих страниц, что гарантирует близость к теоретическому
+   минимуму суммарной стоимости текущих действий и последующих операций.
+
+   На данный момент нет известных практических сценариев ведущих к
+   отказу/неуспеху новой реализации обновления GC. Но гипотетически такие
+   случаи возможны, как из-за ошибок/недочетов в реализации, так и из-за
+   использования катастрофически неудачных режимов работы и значений опций
+   (например `MDBX_opt_rp_augment_limit`). В текущем понимании, в том числе
+   основываясь на объем тестирования, вероятность проявления
+   ошибок/недочетов оценивается как крайне низкая, а устраняться замеченные
+   проблемы будут по мере обнаружения. Однако, полностью автоматическое
+   решение самых кошмарных и запутанных ситуаций с GC следует ожидать
+   только при реализации дефрагментации — просто потому что нет иного
+   рационального способа решения, за вычетом копирования БД с
+   дефрагментацией.
+
  - Добавлена опция сборки `MDBX_NOSUCCESS_PURE_COMMIT` предназначенная для отладки кода пользователя.
    По-умолчанию опция выключена и при фиксации пустых транзакции возвращается `MDBX_SUCCESS`.
    При включении опции, фиксация пишущих транзакций без каких-либо изменений считается нештатным поведением, с возвратом из `mdbx_txn_commit()` кода `MDBX_RESULT_TRUE` вместо `MDBX_SUCCESS`.