По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Семантическое управление версиями (или семвер) – это формальное соглашение для определения номера версии новых выпусков программного обеспечения. Стандарт помогает пользователям программного обеспечения понять серьезность изменений в каждом новом дистрибутиве.
Проект, использующий семантическое управление версиями, объявляет основной номер версии (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.
Заключение
Согласованное использование семантического управления версиями помогает пользователям быть уверенными в вашем проекте. Они могут четко видеть, как развивается ваша кодовая база и нужно ли им самим провести какую-то работу, чтобы идти в ногу со временем.
Объявление строки семантической версии необходимо при публикации в диспетчере наиболее популярных пакетов. Тем не менее, в конечном счете, вам решать, какие номера вы устанавливаете для каждого нового выпуска. Соблюдение стандарта четко сообщает о ваших намерениях пользователям и сводит к минимуму риск непреднамеренного нарушения чужой работы.
Про хоботистый проект, который изменил многое
Интернет, на текущее время, это непрерывно развивающаяся сеть планетарного масштаба. Ее существование невозможно представить без поисковых программ и социальных сетей. Большинство пользователей интернета, ежедневно заходящих в Facebook или ищущих информацию в Yahoo, даже не задумываются, как работает эта система то есть, контактируют только с пользовательским интерфейсом программы. И мало кто знает, что продукты такого типа работают на основе распределенных программам. Их работа основана на кластерах наборах узлов, которые используются для поиска нужной клиенту информации. И одним из основных наборов инструментов, который используется при разработке такого рода программ, является Hadoop.
Что же это такое? Как говорилось выше, это не отдельная программа, а целый набор инструментов, библиотек и приложений, а также инструмент для удобной работы с ними. Для удобства, назовем весь этот комплекс "фреймворком". Всё это предназначено для разработки и использования распределенных программ. В этой статье мы разберемся, из чего состоит основной инструментарий Hadoop и упомянем о самых распространенных программах из набора.
Строго говоря, разработчиком Hadoop является компания Apache Software Foundation. Однако, в силу того, что данный набор программ является свободно распространяемым, ряд сторонних разработчиков (Hortonworks, MapR, Cloudera) создали на основе Apache Hadoopряд своих сборок, которые завоевали у пользователей большую популярность. Это произошло потому, что такие сборки гораздо стабильнее ведут себя в работе и гораздо удобнее в использовании.
Основной базовой частью Hadoop является распределенная файловая система HDFS. От обычных файловых систем ее отличает то, что хранение и работа с файловыми дескрипторами осуществляется с отдельного сервера имён, а данные находятся на отдельных серверах данных. Это делает систему исключительно надежной, поскольку даже при внештатных ситуациях процент безвозвратной потери данных очень мал. Кроме того, система позволяет узнать, на какой конкретной машине расположен интересующий блок данных.
Пару слов о движках: Развитие проекта привело к тому, что классическая схема MapReduce, с которой проект начинал свою работу, сейчас заменяется на варианты Spark или Tez, поскольку значительно ускоряют работу с данными. Spark более универсальная модель движка, применяемая повсеместно, Tez в свою очередь более узко специализирован.
К наиболее популярным системам управления базами данных в данном решении можно отнести базовый вариант Hive, а также альтернативные варианты, такие как Impala от Cloudera, или Spark SQL. Данные продукты имеют свои достоинства и недостатки, но возможность выбора лучшего решения делает проект в общем и целом достаточно гибким и удобным для пользования.
Свою нишу в данном проекте также имеет отдельная NoSQL-база Hbase. Это важное решение для всей системы Hadoop, поскольку эффективно поддерживает работу с отдельными записями в режиме реального времени.
Для импорта данных на текущий момент, пожалуй, единственным эффективным вариантом остается Kafka от оригинального разработчика Apache. Уникальность данного решения в том, что импорт серьезных объемов данных в данном случае заложен в саму архитектуру проекта. Конечно, Kafka обладает рядом минусов, но работы над обновлением и оптимизацией ведутся постоянно.
Помимо этого набора программ, который можно считать базовым, Hadoop обладает рядом других полезных инструментов. Это и алгоритмы машинного обучения для оптимизации работы всей системы (MLlib, Mahout), и программа-координатор ZooKeeper, обладающая широчайшими возможностями по конфигурированию и управлению, программы для планирования задач в проектах Azkaban и Oozie, а так же многие другие подключаемые модули различного назначения и, соответственно, различной полезности в рамках того или иного проекта.
Всем привет! В данной статье хотелось бы познакомить вас с очередным модулем FreePBX 13, который, как нам кажется, будет весьма полезен администраторам IP-АТС в процессе наладки и тестирования новых конфигураций. Итак, встречайте – модуль Misc Applications.
Обзор
С помощью модуля Misc Applications можно настроить специальные внутренние номера или же feature code (фича коды), которые можно будет набрать с внутренних телефонных аппаратов (или софтфонов) и получить доступ к любому направлению, настроенному на FreePBX. Не стоит путать этот модуль с другим - Misc Destinations, который позволяет создать различные направления, которые затем могут использоваться в других модулях, как правило, для входящей маршрутизации.
Модуль Misc Applications работает совместно с любым модулем, который может являться направлением, позволяя пользователям получить доступ к данному направлению, даже если у него нет назначенного номера. Именно поэтому данный модуль – это отличный инструмент для администратора FreePBX, ведь с помощью него мы можем, например, протестировать функционал только что настроенного IVR, DISA, Time Conditions и многих других, без необходимости звонить “снаружи”.
Настройка
Итак, давайте перейдём к настройке. Открываем FreePBX, далее Applications → Misc Applications, и в появившемся окне нажимаем + Add Misc Application
Перед нами открываются доступные функции данного модуля:
Enable - включает и выключает работу данной настройки;
Description - описание, позволяющее идентифицировать цель данной настройки;
Feature Code - внутренний номер или feature code (фича код), который нужно набрать, чтобы получить доступ к направлению;
Destination - направление, по которому попадут пользователи, набравшие feature code или номер;
На примере ниже, мы создали простейшую настройку Dial_into_IVR, которая позволит внутренним абонентам попасть в IVR под названием 2nd_Stage_IVR, после того как они наберут внутренний номер 1510
Помимо этого, модуль Misc Applications можно использовать как инструмент для блокировки набора определённых номеров. Например, если вы не хотите, чтобы внутренние абоненты вашей IP-АТС Asterisk имели возможность звонить по телефонному номеру 1234567890, то вы можете прописать его в данном модуле и выставить направление - Terminate Call (завершить вызов) или Announcement, голосовое сообщение, которое сообщит пользователю о том, что звонки по данному направлению недоступны.