Стоит ли планировать patch и minor релизы?

[inomdzhon]

Как сейчас?

Сейчас все patch и minor изменения сливаются с master и получается так, что если в master с patch изменением попадает minor изменение, то необходимо релизить minor версию вместо patch версии.

Возможная проблема

У пользователя проблема, которая решается patch изменением, соотвественно он ожидает patch версию. Но есть вероятность, что он получит path изменения в minor версии пакета. Может быть так, что на minor версию в его проекте будет проблематично обновляться.

[stoope]

Подскажи плз почему пользователю может быть сложно обновиться на минор? Мы не ломаем существующий функционал

[stoope]

Тогда нам лучше подумать над тем как не допустить breaking changes в минорах чем менять флоу релизов

[inomdzhon]

В идеале да.

Самое банальное, создать шаблон для PR, где будет

- [ ] Обратносовместимое изменение

А дальше уже на Code Review досматривать.

---

Хммм, при всём при том, есть сложность в определении типа изменение: patch, minor, major.

Например, вот этот кейс каким обновлением считать?

< const Component = ({ children, getRootRef }) => {
<   return (
<     <div className="Component" ref={getRootRef}>
<       <div className="Component__inner">
<         {children}
<       </div>
<     </div>
<   );
< };

> const Component = ({ children, getRootRef }) => {
>   return (
>     <div className="Component" ref={getRootRef}>
>       {children}
>     </div>
>   );
> };

---

По мотивам сообщения Антона поискал по релизам и в v4.24.0 увидел изменение

Tappable: теперь вместо селектора :focus-visible, который не работает в safari, используется решение на js.

звучит как breaking change, потому что кто-то мог завязаться на :focus-visible, чтобы перебить стили. Если бы я ждал изменения "Switch: исправлен курсор в disabled-режиме" и при этом в проекте было бы перебитие :focus-visible, то было бы проблематично обновится.

[SevereCloud]

Подскажи плз почему пользователю может быть сложно обновиться на минор?

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

[SevereCloud]

Также патч версии подразумевают собой только исправления. А различные улучшения(в том числе рефакторинг) могут сломать другую часть кода

Например

• v1.1.0 произошел баг с компонентом A
• v1.2.0 баг с компонентом A исправлен, но при улучшении сломали компонент B

С патч версиями

• v1.1.0 произошел баг с компонентом A
• v1.1.1 баг с компонентом A исправлен
• v1.2.0 при улучшении сломали компонент B

[inomdzhon]

Подскажи плз почему пользователю может быть сложно обновиться на минор?

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

Поэтому и думаю не стоит ли планировать релизы. Можно по Git Flow пойти. Есть ветка release/1.1.1 куда будут мержиться патч изменения. Параллельно живёт release/1.2.0, чтобы изменения с улучшениями не ждали release/1.1.1.

[inomdzhon]

@SevereCloud настроил GitLab Flow. Подробнее в PR #2759.

Тема закрыта 🎉