Size: a a a

DocOps-сообщество

2021 April 30

PD

Phil Delgyado in DocOps-сообщество
Увы, но есть дофига доменов, где быстро выкатывать изменения не получается.
Коробочная продуктовая разработка, например.
источник

rd

rus dacent in DocOps-сообщество
+
источник

PD

Phil Delgyado in DocOps-сообщество
Ну и как только частью продукта является API, то понятие "мажорная версия" становится абсолютно логичным
источник

ML

Maksim Lapshin in DocOps-сообщество
и? Вот я такое делаю. Именно потому что быстро выкатывать изменения нельзя, ровно поэтому никаких мажорных изменений делать нельзя.

Нужно иметь возможность давать клиентам время на переезд, а это значит, что продукт целый год одновременно и версия 2, и версия 3.

Именно поэтому термин «мажорная версия» бессмысленнен, потому что не отражает реальность.
источник

PD

Phil Delgyado in DocOps-сообщество
Угу. Поэтому можно говорить о поддержке совместимости в рамках двух мажорных версиях
И о гарантиях обновлений в рамках двух мажорных версиях
источник

PD

Phil Delgyado in DocOps-сообщество
И мажорная версия - это как раз про новое API (с поддержкой старого какое-то время)
источник

ML

Maksim Lapshin in DocOps-сообщество
и именно поэтому _мажорная версия_ — бессмысленный термин.

Если ты говоришь, что у тебя semver, то ты _сам_ декларируешь обратную несовместимость между соседними мажорными версиями.

И сразу же ты заявляешь об их совместимости. Не, никакого противоречия?

вот так, если на секундочку перестать держаться за свои _привычки_ ?
источник

PD

Phil Delgyado in DocOps-сообщество
Смотри, у продукта "API" вполне себе semver
Но при этом мы поставляем два продукта с разными мажорными версиями и оба работают.
источник

ML

Maksim Lapshin in DocOps-сообщество
да в чём заключается то семвер твоего продукта?

Я могу поставить одну инсталяцию твоего софта и к ней обращаться как по старому, так и по новому?
источник

PD

Phil Delgyado in DocOps-сообщество
Ага, так как нет версии всего нашего софта, есть версии отдельных компонент со своими версиями и графиком совместимости.
И да, можно поставить компоненты API разных версий.
источник

ML

Maksim Lapshin in DocOps-сообщество
т.е. вот мы уже отказались от семвера для всего продукта, правильно?

Теперь есть версии отдельных компонент, так?
источник

PD

Phil Delgyado in DocOps-сообщество
Там вообще нет понятия "версия" )
источник

PD

Phil Delgyado in DocOps-сообщество
Вообще, если понятие версия вылезает  -то там можно брать семвер, можно брать номер коммита - примерно пофиг.
источник

PD

Phil Delgyado in DocOps-сообщество
Версия - это всегда фикция и все подходы к версионированию - достаточно бесполезны.
Но, так как клиенты привыкли к семверу - то используем его.
источник

PD

Phil Delgyado in DocOps-сообщество
Ну и если нет задач поддержки совместимости по версиям (а это довольно часто так), то семвер можно использовать без проблем
источник

ML

Maksim Lapshin in DocOps-сообщество
> Версия - это всегда фикция

именно!  Хорошо, что ты согласился.

У calver есть одно преимущество над номером коммита: становится ясно, насколько это старая вещь. А вот по semver вообще ничего сказать о продукте  нельзя.
источник

PD

Phil Delgyado in DocOps-сообщество
Не, calver мало показателен, на самом деле. Так как предполагает "одну версию", что не бывает.
И не показывает, насколько крупные изменения относительно прочих компонент.
Например, семвер позволяет делать правила вида "компоненты с одной major ver гарантированно совместимы друг с другом" и т.п.
источник

PD

Phil Delgyado in DocOps-сообщество
Ты сам говоришь про "совместимость на версию назад" - а это тоже про семвер )
источник

ME

Maria Ermakovich in DocOps-сообщество
мне не показалось, что автор хочет писать документацию, он хочет, чтобы команда писала документацию)
источник

ME

Maria Ermakovich in DocOps-сообщество
ой, кажется я некропостер
источник