К чему я всё это вообще писал?
Я хотел показать на примере (и это уже не в первый раз), как можно сделать больно множеству людей сразу.
Давайте рассмотрим правильный способ выпускать мажорные версии популярных библиотек и сразу разберемся почему это правильный способ, а не просто моё мнение.
Вброс:1. Все новые фичи должны выпускаться в минорных релизах.
2. Мажорные релизы должны только удалять устаревшие фичи, помеченные таковыми 2 мажорных релиза назад.
Обоснование:Давайте рассмотрим самый обычный релизный цикл без следования этим двум правилам:
1.0
— вводим фичу A
1.1
— вводим фичу Б
2.0
— удаляем фичу А
2.1
— вводим фичу Д (чтобы не путать с алфавитом ABC)
Теперь, пользователи библиотеки вынуждены переписать своё приложение на новое API, чтобы получить фичу Д.
А если версия
1.x
больше не поддерживается, то они обязаны это сделать, чтобы получать обновления безопасности.
А если библиотека имеет peerDependencies, то они также обязаны, чтобы обновлять другие свои зависимости.
Если библиотека серьезно ломает совместимость (как react-router много раз), то рефакторинг может серьезно затянуться и тем самым остановив получение обновлений безопасности, вынуждая использовать костыли, вроде
yarn resolutions.
Как правильно:А теперь, что будет если следовать этому правилу:
1.0
— вводим фичу А
1.1
— вводим фичу Б
2.0
— вводим фичу Д (которая по сути должна заменять фичу А) и депрекейтим фичу А
3.0
— удаляем фичу А
Теперь у потребителей библиотеки есть целых ДВА мажорных релиза, чтобы обновиться и при этом не терять обновления безопасности. Да, это сделает больнее разработчикам библиотеки, но если библиотека популярная, придется уважать своих пользователей и не превращать их жизнь в ад обновления зависимостей.
В сложных библиотеках/фреймворках есть roadmap и migration guide, который частично снижает боль. На мой взгляд, 2 мажорных релиза, один из которых вешает депрекейты это отличный компромисс между полной обратной совместимостью java и react-router.
Я должен отметить, что новые фичи обязаны не перекрещиваться своим API со всеми существующими ДО этого API в предыдущих версиях, иначе получится проблема обновления через несколько версий:
Пользователь был на версии
1
в которой метод назывался
navigate и принимал 2 аргумента.
В версии
2
, метод задепрекейтили и удалили в версии
3
.
А уже в
4
версии добавили метод с названием
navigate, но с другим смыслом и набором аргументов.
Если пользователь будет обновляться с
1
версии сразу на
4
, то он может попасть в ситуацию, когда метод
navigate в javascript не бросает исключений, он просто тихо и спокойно работает, но работает совершенно не правильно.
За инсайт спасибо
@ZeroBiasЛюбите своих пользователей 🧡