Основные и дополнительные версии: что важно знать о версиях ПО и SharePoint

By Mirko Peters · 2026-05-25 · Updated 2026-07-16

Сравнение основных и дополнительных версий в SharePoint: черновики, публикация, согласование, видимость, история версий, разрешения, восстановление и управление документами.

Automatically translated with AI from the original post. Read the English original

Titelbild: Major vs Minor Versions Explained: Software and SharePoint Insights

Понимание основных и дополнительных версий нужно не только разработчикам и ИT-специалистам. Это важно каждому, кто работает с современными цифровыми системами. Выпускаете ли вы программное обеспечение, обновляете библиотеки SharePoint или отвечаете за управление в Microsoft Teams, знание различий между типами версий помогает всем действовать согласованно.

В этом руководстве разбираются основы версионирования: правила, лучшие практики и то, почему это важно за пределами технического жаргона. Вы увидите, как грамотное управление версиями приводит к более стабильным обновлениям, лучшему взаимодействию и более плавным изменениям во всей организации. И ИТ-специалисты, и представители бизнеса найдут здесь понятные рекомендации по уверенному и ясному внедрению обновлений.

Введение в концепции версионирования и множественные версии

Начнём с основ: «версия» — это просто метка, которая показывает, в каком состоянии находится программа, документ или система в конкретный момент. Номера версий помогают всем отслеживать изменения во времени. Представьте их как контрольные точки на дороге: вы всегда знаете, где остановились и что изменилось с тех пор.

Выделяются два основных типа версий: основные версии и дополнительные версии. Основная версия отмечает крупную веху: это означает, что изменилось что-то существенное, например новые возможности или изменение, не совместимое с предыдущими версиями. Дополнительная версия, в свою очередь, обычно сигнализирует о небольших поэтапных улучшениях, которые опираются на уже имеющееся и часто не нарушают работу того, что уже используется.

Версионирование касается не только программ. Такие платформы, как SharePoint, используют контроль версий для управления изменениями документов и списков, что упрощает просмотр истории или восстановление более ранних черновиков при необходимости. Надёжные практики версионирования снижают риски: если после обновления что-то пошло не так, вы точно знаете, что изменилось. А для организаций понимание различий между типами версий означает более плавные обновления, понятное управление и меньше сюрпризов в период перехода.

Освоив эти основы, технические команды и бизнес-заказчики смогут принимать более взвешенные решения. Планируете ли вы выпуск программ, управляете изменениями в SharePoint или внедряете обновления во всей Microsoft 365, продуманные концепции версионирования станут страховкой, которая помогает контролировать риски и сохранять согласованность всех участников.

Сравнение основных и дополнительных версий: в чём разница?

Граница между основной и дополнительной версией — это не просто номер, а то, насколько сильно каждое обновление может всё встряхнуть. Основная версия обычно представляет собой значительную веху: крупные новые возможности, серьёзные переработки или изменения, не совместимые с прежними, из-за которых пользователям приходится адаптироваться или проходить переобучение. Например, когда программа обновляется с версии 1.0 до 2.0, это не просто косметическое изменение номера: обычно это означает существенно новые возможности или изменение, которое работает не так, как раньше.

Дополнительная версия, напротив, — это скорее мягкий шаг вперёд. Исправления ошибок, небольшие улучшения или новые функции, не нарушающие совместимость. Переход с 1.2 на 1.3 добавляет ценность, часто улучшает работу, но редко мешает текущему использованию или интеграциям. Дополнительные выпуски поддерживают движение вперёд, не заставляя пользователей менять свои рабочие процессы.

Поводом для основного обновления могут стать новый пользовательский интерфейс, изменение, нарушающее существующие интеграции, или удаление старых функций. Дополнительные версии, напротив, выпускаются при добавлении функций с сохранением совместимости: дополнительные параметры, доработки или повышение производительности, которые никому не помешают. В SharePoint публикация документа как основной версии означает, что он официально утверждён и видим всем, тогда как дополнительные версии позволяют командам совместно работать и вносить правки, которые остаются скрытыми, пока не будут готовы к показу.

Чёткая маркировка выпусков как основных или дополнительных помогает планировать развёртывание и соблюдать требования соответствия, заранее информируя ИТ-специалистов и конечных пользователей о том, чего ждать. Основные версии могут требовать нового обучения или коммуникаций, тогда как дополнительные могут выходить без лишнего шума. В конечном счёте понимание разницы между ними укрепляет доверие пользователей, держит риски совместимости под контролем и упрощает стратегии поддержки и внедрения.

Семантическое версионирование в разработке ПО

Семантическое версионирование, или SemVer, стало золотым стандартом управления релизами программного обеспечения. Это больше, чем соглашение об именовании: это способ задать чёткие ожидания относительно того, что принесёт каждая новая версия продукта. Стандартизируя то, как назначаются и увеличиваются номера версий, SemVer позволяет с первого взгляда понять, является ли обновление кардинальной переработкой, безопасной новой функцией или просто исправлением ошибки.

Главное достоинство семантического версионирования — предсказуемость. Если вы поддерживаете программное обеспечение или зависите от внешних библиотек, вам нужно знать, когда можно безопасно обновиться, не сломав ваши решения. С SemVer номер версии сообщает, какую совместимость можно ожидать, что помогает избежать неприятных сюрпризов и проблем с зависимостями.

В этом разделе мы подробно разберём, что на самом деле означает семантическое версионирование, рассмотрим знаменитую спецификацию 2.0.0, объясним, почему так много команд её поддерживают, и покажем, как она помогает управлять публичными API и плавно выводить функции из эксплуатации. Освоив эту систему, команды могут эффективнее взаимодействовать и уверенно выпускать обновления, зная, что они подкреплены понятной и последовательной историей версий.

Спецификация семантического версионирования 2.0.0 и формат нумерации

Формат номера версии:Семантическое версионирование использует формат MAJOR.MINOR.PATCH (например, 2.3.7). У каждого числа своя роль:

MAJOR—увеличивайте этот номер, когда вносите несовместимые изменения API или другие крупные изменения.
MINOR—увеличивайте, когда добавляете функциональность с сохранением обратной совместимости.
PATCH—используйте для исправлений, сохраняющих обратную совместимость, например для устранения ошибок.

Идентификаторы предварительных версий:Если вы выпускаете что-то до официальной стабильной версии, к концу номера через дефис добавляется метка. Например, 2.3.7-beta или 2.4.0-rc.1. Это показывает, что версия не готова к полноценной эксплуатации в продуктивной среде.
Метаданные сборки:Можно также добавить информацию о сборке после знака +, например 2.3.7+20240605. Это не влияет на сравнение версий, но помогает отслеживать конкретные сборки.
Разбор и правила BNF:SemVer допускает только неотрицательные целые числа, а вся строка версии следует чёткой грамматике Бэкуса–Наура, которую могут разбирать машины. Десятичных чисел нет: это строгая трёхкомпонентная структура.
Пример из практики:Если библиотека переходит с 1.4.2 на 2.0.0, разработчики сразу понимают, что есть несовместимые изменения. Переход с 1.4.2 на 1.5.0 означает, что обновиться безопасно и можно получить новые функции. Переход с 1.4.2 на 1.4.3 сигнализирует только об исправлениях ошибок.

Зачем использовать семантическое версионирование?

Предсказуемые обновления: Команды знают, какой риск несёт каждое повышение версии, и обновления перестают пугать.
Лучшее управление зависимостями: Разработчики могут задавать правила, по которым принимаются только совместимые версии, снижая риск поломок.
Понятная коммуникация: Все, от ИТ до бизнеса, могут быстро увидеть, является ли обновление мажорным, минорным или исправлением, без догадок.
Доверие и стабильность: Команды и пользователи охотнее обновляют системы, когда версионирование надёжно и прозрачно.

Как выводить функциональность из эксплуатации и версионировать публичные API

Помечайте функции как устаревшие до удаления:Чётко отмечайте устаревшие функции как «deprecated» в документации, заметках о выпуске и аннотациях к коду. Предупредите пользователей заранее, что функция исчезнет в будущих релизах.
Сообщайте и задавайте сроки:Указывайте сроки удаления и заранее объявляйте о критических изменениях, за несколько версий до их появления. Точные сроки позволяют пользователям подготовиться, что уменьшает раздражение и количество неожиданностей.
Предлагайте пути миграции:При выводе функции из эксплуатации всегда давайте альтернативы или руководства по миграции, чтобы пользователи могли плавно перейти от старой функциональности. Это могут быть примеры кода, сравнения «бок о бок» или инструменты автоматической миграции.
Увеличивайте мажорную версию при несовместимых изменениях:Если вы удаляете или существенно меняете публичные API так, что это ломает существующее использование, по правилам SemVer это всегда должно приводить к увеличению MAJOR. Это сигнализирует всем пользователям о риске и необходимости действий.
Согласуйте с дорожными картами продуктов:Планируйте вывод функций из эксплуатации и их удаление в соответствии с более широкими дорожными картами продуктов. Отмечайте эти вехи в публичных планах и объявлениях о релизах, чтобы заинтересованные стороны были в курсе и не паниковали.
Отслеживайте и учитывайте отзывы:После выпуска изменений собирайте отзывы пользователей и отчёты об ошибках. Будьте готовы откатить или оперативно исправить критичные изменения, если обнаружите проблемы с внедрением.

Управление версиями в SharePoint: списки, библиотеки и страницы

В отличие от традиционного ПО, SharePoint переносит управление версиями в мир рабочих документов, списков и пространств для совместной работы. Здесь версии нужны не только для кода: они управляют всем — от правок файлов до изменений политик на уровне всей компании. Основные и дополнительные версии позволяют SharePoint сохранять понятную историю изменений и гарантируют, что команда всегда знает, что уже опубликовано, а что ещё находится в работе.

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

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

Интересно, как управление версиями в SharePoint соотносится с другими инструментами Microsoft 365? Посмотрите это сравнение: Teams или SharePoint: сравнение панелей мониторинга. Там показано, как разные платформы подходят разным аудиториям и задачам.

Как включить дополнительные версии и управление версиями в списках и библиотеках

Откройте настройки библиотеки или списка:Перейдите на свой сайт SharePoint, откройте нужную библиотеку документов или список и выберите «Параметры библиотеки» или «Параметры списка».
Найдите настройки версий:Нажмите ссылку «Параметры управления версиями». Здесь настраиваются все параметры версий.
Включите основные и дополнительные версии:Выберите «Создавать основные и дополнительные (черновые) версии». Это позволяет сохранять черновики в закрытом виде до их публикации в качестве основных версий.
Настройте утверждение содержимого:При необходимости включите утверждение содержимого, чтобы дополнительные изменения требовали проверки перед тем, как станут общедоступными. Это удобно для конфиденциального содержимого или задач соответствия требованиям.
Сохраните и примените параметры:Нажмите «ОК», чтобы сохранить настройки. Дополнительное управление версиями теперь активно и обеспечивает более строгий контроль документов и журналы аудита.

Управление хранимыми версиями и определение черновых элементов в SharePoint

Политики хранения версий:Ограничьте количество сохраняемых версий, задав максимум в параметрах управления версиями. Это помогает предотвратить неконтролируемый рост объёма хранилища.
Разрешения на черновые элементы:Выберите, кто может видеть черновые (дополнительные) версии. Обычно это только пользователи с разрешением «Редактирование» или определённые группы, что позволяет держать конфиденциальные правки закрытыми до публикации.
Просмотр истории версий:Пользователи могут просматривать историю версий, чтобы отслеживать изменения, восстанавливать более ранние версии или видеть, кто внёс конкретные правки. Это поддерживает аудит соответствия требованиям и диагностику проблем.
Разрешения библиотеки:Назначайте детальные разрешения для пользователей или групп, чтобы контролировать, кто может редактировать, удалять или восстанавливать версии. Это ключевой момент для регулируемых команд и конфиденциального содержимого.
Советы по управлению содержимым:Регулярно очищайте старые или ненужные черновики и настраивайте оповещения об изменениях версий, чтобы контролировать важные библиотеки и не утонуть в лишних файлах.

Утверждение содержимого, извлечение версий файлов и обязательное извлечение в библиотеках

Настройте утверждение содержимого:Включите утверждение содержимого в параметрах управления версиями, чтобы дополнительные или основные версии публиковались только после проверки. Это используется для официальных документов или страниц, требующих контроля.
Извлечение и возврат файлов:Требуйте извлекать файлы перед редактированием, чтобы изменения вносил только один пользователь одновременно. При возврате создаётся черновик (дополнительная версия), что снижает риск случайной перезаписи.
Обязательное извлечение:Заставьте пользователей извлекать документы перед любыми правками. Это дополнительный уровень контроля, идеальный для юридической и регулируемой среды, а также устранение путаницы из-за одновременного редактирования.
Порядок создания версий:Каждый возврат, будь то дополнительная или основная версия, создаёт новую версию. Так для каждого документа формируется подробная история изменений и утверждений.
Сценарии для контроля качества и соответствия требованиям:Объедините процессы согласования, управление версиями и резервирование на изменение (check-out) для чувствительных процедур, например при публикации изменений в политиках, финансовых отчётов или юридических документов, чтобы ничего не проскочило без проверки и утверждения.

Схемы нумерации версий: технические подходы и примеры из реального ПО

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

Разные отрасли и проекты выбирают разные схемы. Иногда встречается версия вида 2024.06 (календарная), иногда просто 105 (последовательная), а иногда более описательная 1.2.3 (семантическая). Каждая из них находит своё применение в зависимости от того, как развиваются программы, документы или платформы, как организовано соответствие требованиям и как часто выходят релизы.

Далее мы рассмотрим наиболее распространённые модели версионирования и посмотрим реальные примеры из практики таких технологических гигантов, как Apple, Microsoft и проект Python с открытым исходным кодом. Изучив, как это делают профессионалы, вы поймёте, что подойдёт для ваших собственных проектов, будь то стремление к ясности, соответствию требованиям или и то, и другое.

Распространённые схемы версионирования: последовательные идентификаторы и идентификаторы дат релиза

Семантическое версионирование (SemVer): использует формат MAJOR.MINOR.PATCH (например, 3.1.4). Понятно указывает на совместимость и характер изменений. Отлично подходит для проектов с открытым исходным кодом и API.
Версионирование по дате (CalVer): использует даты вида YYYY.MM (например, 2024.06). Распространено у продуктов с регулярными плановыми релизами, например у Ubuntu Linux.
Последовательная нумерация: просто увеличивается по порядку (например, 101 → 102). Используется для внутренних сборок или систем, где важен только порядок.
Комбинированные модели: некоторые организации используют смесь схем, например семантическое версионирование для релизов для клиентов и последовательную нумерацию для внутренних сборок.

Примеры из ПО: как Apple, Microsoft Windows и Python управляют версиями

Apple macOS/iOS: крупные новые функции или переработка дизайна приводят к скачкам основной версии (например, iOS 15 → iOS 16), а инкрементальные исправления отвечают за мелкие улучшения и ошибки.
Microsoft Windows: Windows использует основные версии (например, Windows 10, 11), а также подверсии с указанием даты (например, 21H2) для крупных обновлений и патчей.
Python: каждая основная версия (2, 3) вносит изменения, нарушающие совместимость, подверсии (например, 3.11) добавляют новые возможности, а патч-версии исправляют ошибки. Очень наглядно с точки зрения влияния на систему.
Проекты с открытым исходным кодом: такие проекты, как Node.js и Linux, сочетают семантическое версионирование с привязкой к датам для веток или релизов LTS, балансируя между стабильностью и графиком выпусков.

Продвинутое версионирование: предварительные релизы, обновление зависимостей и регулярные выражения

Не каждая версия готова к использованию в продуктивной среде: некоторые ещё находятся в стадии «alpha», «beta» или «release candidate» (RC). Пометка таких версий как предварительных помогает разработчикам и пользователям понять, что безопасно для тестирования, а что готово к производству. Грамотное управление этими версиями подразумевает использование лучших практик обновления зависимостей и наличие надёжных правил для выявления ошибок в строках версий.

В современном автоматизированном мире DevOps номера версий часто задаются скриптами, конвейерами или сообщениями коммитов, а не вручную. Регулярные выражения (regex) позволяют гарантировать, что форматы версий корректны и единообразны во всех системах, что помогает устранить ошибки релиза до того, как они дойдут до клиентов.

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

Использование предварительных версий и рекомендуемых регулярных выражений для проверки версий

Теги предварительных релизов: используйте метки вроде -alpha, -beta или -rc.1, чтобы отметить версии на стадии тестирования или с незавершённой функциональностью. Это помогает тестировщикам, а не конечным пользователям, получать нужные обновления.
Проверка версий: применяйте регулярные выражения (regex), например ^(\d+)\.(\d+)\.(\d+)(?:-[\w\.]+)?(?:\+[\w\.]+)?$, чтобы подтвердить корректность форматов вроде 1.2.3-beta+exp.sha1.
Единообразие в CI/CD: автоматизируйте проверки версий в конвейерах сборки, чтобы блокировать релизы, не соответствующие вашему стандарту. Это снижает риск случайных пропусков версий и путаницы.
Безопасные обновления зависимостей: используйте диапазоны версий и строгое сопоставление по регулярным выражениям в системе управления пакетами, чтобы не допускать попадания нестабильных или несовместимых предварительных сборок в критически важные системы.

Дополнительные сведения, лицензирование и главное о значимости версий

В завершение отметим: то, как вы работаете с основными и второстепенными версиями, — это не просто техническая деталь. Она помогает формировать доверие пользователей, управлять рисками и поддерживать репутацию организации. Правильное версионирование — это хороший маркетинг, и оно избавляет всех от лишних проблем в будущем, когда что-то меняется. Понятное версионирование упрощает отслеживание и управление обновлениями как для вашей ИТ-команды, так и для бизнес-пользователей.

Многие стандарты версионирования программного обеспечения, например Semantic Versioning (SemVer), открыты и развиваются сообществом. Сам SemVer опубликован под лицензией Creative Commons CC BY 3.0, которая позволяет использовать и адаптировать его в своих проектах при условии правильного указания авторства. Прежде чем встраивать инструменты и спецификации в свой рабочий процесс, всегда проверяйте их лицензии.

Если вы хотите поддерживать свои знания в актуальном состоянии, обратитесь к сообществам, обсуждениям на GitHub или документации Microsoft Learn по версионированию в SharePoint. Там всегда найдутся специалисты, готовые обсудить лучшие практики. Отзывы, будь то реакция пользователей на крупное обновление или мысли разработчиков об автоматизации, должны возвращаться в вашу стратегию версионирования для постоянного совершенствования.

Итог: подходите к основным и второстепенным версиям осознанно. Делайте обновления понятными для всех, особенно для тех, кто далёк от ИТ. Грамотно используйте открытые стандарты и не стесняйтесь обращаться к сообществу за свежими идеями. Продуманное версионирование — это не только номера, это доверие, контроль и спокойная работа на каждом этапе.

Вам также стоит послушать

Понимание различий между основными и второстепенными версиями SharePoint помогает командам отделять черновики от опубликованного контента и связывать решения о редактировании, согласовании, видимости и хранении. Эти выпуски рассказывают о документной системе в целом:

Исправляем хаос документов в Dynamics 365 и SharePoint — Как архитектура документов, интеграции, разрешения и выбор жизненного цикла влияют на масштабируемое управление контентом.
Останавливаем разрастание SharePoint с помощью управления данными и автоматизацией — Как жизненный цикл, владение, автоматизация и управление контентом предотвращают долгосрочное разрастание SharePoint.
Аудит доступа к данным Microsoft 365 перед развёртыванием Copilot — Как разрешения, владение, избыточный общий доступ и границы данных влияют на безопасность и готовность к ИИ.
Устранение пробела в метаданных SharePoint для ИИ и управления — Как классификация и метаданные упрощают поиск, управление и использование документов с ИИ.