Очистка кода нарушает бинарную совместимость

Я работаю над проектом, которым пользуются люди, которых я не знаю. Мы проделали довольно хорошую работу по устранению предупреждений CheckStyle, и дело в том, что их можно достичь без нарушения бинарной совместимости.

Большинство оставшихся предупреждений вызвано тем, что в константах (public static final) отсутствует ключевое слово final. Именование констант дает понять, что разработчик предназначал их только для чтения, но для них просто не было окончательного определения.

Если разработчик не писал довольно ужасный код, в котором использовалась эта оплошность, его код не сломается, если мы их добавим.

В настоящее время номер версии - 1.2.1. Примените ли вы изменение и перейдете к версии 2.0, или примените его и разверните как версию 1.3. Похоже, это довольно небольшое изменение, требующее полной версии 2.0.

Что я должен делать?


java versioning checkstyle binary-compatibility
person Allain Lalonde    schedule 19.10.2009    source источник
comment
Разве что разработчик писал какой-то довольно ужасный код, который использовал бы эту оплошность - или, возможно, чтобы обойти плохо спроектированный API?   -  person Ed S.    schedule 19.10.2009
comment
@mmyers: Интересно, как вы пришли к выводу, что это связано с Java: -?   -  person OscarRyz    schedule 19.10.2009
comment
@Oscar Reyes: Назовите другой язык с ключевым словом final для констант.   -  person Powerlord    schedule 19.10.2009

Ответы (4)


arrow_upward
3
arrow_downward

Я уверен, что вы это уже знаете, но я подозреваю, что это должно сводиться к тому, "это безопасное / простое / не вызывающее беспокойства" обновление?

  • Точечные релизы считаются безопасными и обычными. Они должны полностью состоять из исправлений ошибок в некоторых проектах. Другие проекты будут включать новые функции, если они вряд ли вызовут проблемы.
  • Выпуски новых основных версий содержат эволюционные изменения, которые могут потребовать адаптации
  • Новые выпуски основной версии x.0 вызывают большие подозрения у опытных пользователей :-)

Я думаю, это также зависит от того, насколько вы близки к выпуску следующей основной версии. Если это скоро, не рискуйте выпуском проблемных точек. Вы всегда можете сделать безопасный точечный релиз и альфа-мажорный релиз, но это могло бы быть странно, если бы следующий мажорный релиз был далеко в будущем ...

person DigitalRoss    schedule 19.10.2009

arrow_upward
4
arrow_downward

На мой взгляд, подобные изменения, которые могут нарушить двоичную совместимость, следует отложить до выпуска основной версии. То есть ваш вопрос должен быть не «Какой номер версии мне использовать», а скорее «когда мне следует делать эти изменения».

Если вы полностью привержены бинарной совместимости, вам следует отложить эти изменения до выпуска, который будет содержать значительные улучшения, оправдывающие стоимость обновлений. Например, проект KDE налагает требование двоичной совместимости для основных выпусков. Это означает, что любые улучшения за время существования этого выпуска не могут повлиять на приложения, скомпилированные для более старых версий. Поэтому разработчики, желающие очистить код, должны дождаться следующей основной версии.

Как только вы будете готовы выпустить основной выпуск со всеми его шикарными новыми функциями, продолжайте вносить любые изменения двоичной совместимости, которые вы считаете необходимыми, и в этом случае, если что-то сломается, это не так удивительно.

Если вы хотите быть умным, вы можете реализовать препроцессор и скомпилировать код дважды, один раз с финалом, а другой - без него. Это можно было бы использовать как ступеньку к истинному финалу, но тем временем затраты на обслуживание будут высокими.

person Mr. Shiny and New 安宇    schedule 19.10.2009

arrow_upward
2
arrow_downward

Я говорю, сломайте их. Если вы мутирующий статик, вы должны знать, что делаете неправильно. Однако вы можете выделить его в другой выпуск, чтобы у клиентов была возможность (независимо от того, принимают они это или нет) плавно, а не в панике, потому что им нужно какое-то другое, не связанное с этим исправление.

person Tom Hawtin - tackline    schedule 19.10.2009

arrow_upward
0
arrow_downward

Если разработчик не писал довольно ужасный код, в котором использовалась эта оплошность, его код не сломается, если мы их добавим.

Как создание подклассов ранее незавершенных классов, которые больше не будут работать?

Я думаю, это должна быть версия 2.0, и вы должны продолжать поддерживать серию 1.x.

Кроме того, вот интересное видео об API: "Как разработать хороший API и почему это важно "создателем Джошуа Блоха, поэтому основные библиотеки на Java и теперь работают в Google

person OscarRyz    schedule 19.10.2009
comment
Это были не классы, а константы, которым не хватало финала. - person Allain Lalonde; 20.10.2009
comment
Вы можете остановить модификации этих статических атрибутов. Например, вы могли сломать что-то вроде: if( YourClass.intField++ > 1 ){... - person OscarRyz; 20.10.2009