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

Question

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

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

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

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

Что мне делать?

Answer 1

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

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

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

Answer 2

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

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

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

Кроме того, вот интересное видео о API: «How to design a good API and why it matters» Джошуа Блоха создатель так основные библиотеки в Java и сейчас работает на Google

Answer 3

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

Answer 4

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

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

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

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