Мажорный, минорный, патч: что техническому писателю стоит знать про релизы Откуда вообще взялись понятия «мажорный», «минорный» и «патч»? «Уши растут» из SemVer. Это соглашение о том, как нумеровать версии программного обеспечения, чтобы по номеру было понятно, какого плана (и объема) изменения произошли в рамках релиза. Номер версии выглядит так: MAJOR.MINOR.PATCH (например, 3.2.1). Пройдемся по каждому виду релиза: 1. Патч-релиз (x.x.PATCH). Для его обозначения используется третья цифра. Такой релиз включает мелкие обновления и изменения. Это могут быть исправления багов, мелкие правки, которые не ломают обратную совместимость и пр. Пример такого обновления: устранение бага, из-за которого в некоторых ситуациях кнопка работала некорректно. Release notes для патч-релизов обычно краткие и по делу. Зачастую они содержат один раздел «Исправления». Что касается документации, в этом случае правки вносятся, как правило, только в разделы, где была описана некорректная функциональность. 2. Минорный релиз (x.MINOR.x). Для его обозначения используется вторая цифра. Такой релиз включает значительные обновления, которые добавляют новую функциональность, но не ломают существующие функции, API и интерфейсы. Еще одна особенность такого релиза — сохранение обратной совместимости. Пример: добавление возможность отправки видео в мессенджере. Старые чаты и текстовые сообщения при этом никуда не деваются, все продолжает работать. Release notes для минорных релизов должны понятно представить новые фичи, объяснить их пользу для пользователя. Один из вариантов структуры: «Новые возможности», «Улучшения», «Исправления». Что касается документации, в этом случае техпису предстоит довольно объемная работа. Как правило, для доки создаются новые разделы, обновляются (часто довольно сильно) существующие и т.д. 3. Мажорный релиз (MAJOR.x.x). Для его обозначения используется первая цифра. Такой релиз включает глобальные обновления, которые ломают обратную совместимость. Пример: изменение (замена) API с потерей обратной совместимости, кардинальные переработки интерфейса, удаление устаревших функций. Release notes в таком случае — это почти пресс-релиз. Здесь не просто перечисляются изменения, при подготовке RN придется объяснить почему это было сделано, каковы преимущества нового подхода. Часто такие RN включают раздел «Критические изменения» или «Миграционное руководство» (примерные названия). Что касается документации, ее в таком случае ждет полная ревизия и переработка. Переписываются целые разделы, создаются новые, делаются гайды по переходу со старой версии... В общем, ведется серьезная и сложная работа.