Влияет ли добавление новой зависимости в библиотеку на двоичную совместимость, если внешний API библиотеки иначе обратимся обратно?
My Библиотека CBOR содержит классы для арифметики произвольной точности (в пространстве имен PeterO). (Это в С# и Java, версия Java находится в отдельном репозитории, но эта же проблема относится и к обеим версиям.)
Я переместил эти классы в новое пространство имен (в PeterO.Numbers) и переименовал их (сохраняя исходные классы для обратной совместимости), потому что пространство имен, в котором они сейчас находятся, должно содержать только служебные классы. Я планирую переместить новые классы в отдельную библиотеку и сделать библиотеку CBOR вызывать эту библиотеку как зависимость, так как классы произвольной точности, очевидно, полезны вне CBOR. (Я планирую в конечном итоге отказаться от старых классов.)
Но я обеспокоен тем, что создание отдельной библиотеки таким образом является проблемой двоичной совместимости, поэтому я не могу просто обновить второстепенную версию, но также и основную версию. Библиотека CBOR - это версия 2.3.1 на момент написания этой статьи. Могу ли я сделать это и изменить версию на 2.4 или только 3.0?
Пока вы начинаете работать с интерфейсом, и все клиенты ваших библиотек знают об этом интерфейсе, все будет в порядке. Неважно, где ваш код находится в вашей библиотеке или в библиотеке за ее пределами, если в вашей библиотеке есть интерфейс, который его клиенты понимают, и он реализует интерфейс.
Это старая проблема и была решена 15 лет назад COM (компонентная объектная модель). Держите свои интерфейсы отдельно от реализации, и вы являетесь золотыми.
Я отвечу на версию Java. В этом разделе спецификации языка Java подробно описываются изменения, которые могут быть внесены в приложения при сохранении бинарной совместимости.
Из того, что я понимаю, ваши изменения (хотя они могут повлиять на большую часть источника) - это простые рефакторинги, которые выставляют некоторые классы утилиты другому модулю и перенаправляют старые классы для вызова этого нового модуля. Это описано в разделе Эволюция пакетов:
Новый класс верхнего уровня или тип интерфейса может быть добавлен в пакет без нарушения совместимости с ранее существовавшими двоичными файлами, если новый тип не повторно использует имя, ранее заданное для несвязанного типа.
Таким образом, это не нарушает двоичную совместимость с существующими классами, которые используют вашу библиотеку. Любой существующий класс CBORClient, который использовался для вызова CBORUtil.doArithmetic(), будет продолжать работать без необходимости его компиляции, поскольку метод все еще существует, только его тело изменилось, чтобы вызвать другой модуль для выполнения вычислений.
Лучше избегать добавления новой зависимости до следующей основной версии. До этого добавьте изменения внутри и создайте новую библиотеку произвольной точности с тем же классом и синхронизируйте их без зависимости.
поэтому для версии 2.4 добавьте изменения в новое пространство имен и вызовите их из старого класса и создайте другую библиотеку классов для классов произвольной точности и синхронизируйте их до следующей основной версии для библиотеки CBOR