Мажорное обновление что это
Семантическое управление версиями 1.0.0-rc.1
В мире разработки программного обеспечения, существует страшное место, называемое «ад зависимостей». Чем больше ваша система, тем больше шанс, что в один из дней вы попадете в эту ловушку.
В системе с большим количеством зависимостей, выпуск новых пакетов может быстро превратиться в кошмар. Если зависимости слишком прочные, вы не можете обновить пакет, не обновив при этом версии всех зависимых пакетов. Если зависимости слишком свободные, у вас возникнут проблемы с распущенностью версий. «Ад зависимостей», это когда слишком прочные, или наоборот, слишком свободные зависимости не дают вам легко и безопасно развивать ваш проект.
Как решение этой проблемы, я предлагаю простой набор правил, которые диктуют как присваивать и увеличивать номера версий. Для того, что бы система работала, для начала, вам нужно объявить открытый API. Это должен быть простой и ясный документ. Рассмотрим номер версии в формате X.Y.Z (Major.Minor.Patch).
При исправление ошибок не затрагивающих API увеличивается Patch версия. При добавление или изменение API с сохранением обратной совместимостью увеличивается Minor версия. Если API изменяется без сохранения обратной совместимости, то увеличивается Major версия.
Я называю эту систему «Семантическое управление версиями». Согласно этой схеме, номера версий и то, как они меняются несут в себе смысл об основном коде и о том, как он изменялся от версии к версии.
Спецификация Семантического управления версиями
Ключевые слова «ДОЛЖЕН (MUST)», «НЕ ДОЛЖЕН (MUST NOT)», «СЛЕДУЕТ (SHOULD)», «НЕ СЛЕДУЕТ (SHOULD NOT)», «МОЖЕТ (MAY)», в этом документе должны интерпретироваться в соответствии с RFC 2119.
Что такое минорное обновление: как производится и зачем
Минорное обновление — это один из способов усовершенствовать функциональность работающей программной системы, котор ый обязательно сопровождает программное обеспечение в процессе его жизнедеятельности.
Выход обновлений любого программного продукта является неотъемлемой частью его развития и процветания. Апгрейд программного продукта может содержать:
решение технических проблем;
устранение опасных уязвимостей;
добавление новых функциональных возможностей;
адаптаци ю под новые устройства или платформы;
Минорное обновление — это часть планового внесения изменений
Различают несколько видов внесения изменений в программу:
Минорное обновление. Это уже более массивное усовершенствование системы, которое несет в себе более масштабные изменения в программе, однако не предполагает полноценную смену версии программы. В таких корректировках системы внедряется новый функционал: новая игровая карта, новый режим, новый инструмент и др.
Мажорное обновление. В подобном виде апгрейда происходит комплексное изменение программы, вплоть до ее полной неузнаваемости.
«2.0» — версия программы или мажорное обновление второго поколения;
«1» — версия минорного обновления;
«7» — номер примененного патча.
Например, та же программа может быть версии «2.0.2.8», где сохраняется второе поколение программы, но вн осятся изменени я в виде минорного обновления «2» и патча «8». Если программа будет начинаться на «3.0», то это будет означать, что внесены кардинальные обновления.
Как минорное обновление влияет на пользователей
Чтобы правильно оценить масштабы вероятных изменений в категориях апгрейда, приведем пример:
патч может затронуть только одну строчку кода, чтобы исправить какой-то баг;
при мажорном внесении изменений может произойти смена языка программирования всего проекта или игрового движка в игре.
Заключение
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Версионирование ПО
Видов программ великое множество, и все они сильно друг от друга отличаются. Со временем даже одна система может развиться так, что ее станет не узнать. Как же разобраться во всем этом хаосе? Одним из решений является “Версионирование ПО”, с которым мы познакомимся в этой статье.
Польза от версионирования ПО
Применение версионирования решает следующие основные задачи разработки и сопровождения ПО:
Семантическое версионирование
Представьте, что вы используете пакет для обработки изображений в своей системе “Галерея фотографий”. Вся логика галереи всецело зависит от этого пакета, но пакет часто меняется, в нем появляются новые функции и закрываются старые баги, что постоянно изменяет его версию. Вы конечно же хотите “идти в ногу со временем” и часто обновляете этот пакет, но в один ужасный день вся система перестает работать. Быстрый анализ показывает, что проблема вызвана удалением из пакета одной старой, но используемой галереей функции (назовем ее crop ).
Как же обезопасить свой код от такого рода проблем? Решение есть, оно называется “Семантическим версионированием”. Использование систем, применяющих эту модель версионирования, обеспечивает вас удобным инструментом для контроля за возможными изменениями и совместимостью. Работает это очень просто, нужно всего навсего следовать следующим правилам при выборе версии ПО:
Чтобы было понятнее, рассмотрим несколько примеров:
Если вы увидите, что для используемого вами пакета обработки изображений ImageEditor 1.1.4 изменилась версия до 1.1.5 (патч-версия), смело обновляйте ее, ведь это не нарушит совместимости с вашей галереей.
Альфа, бета и другие имена версий
Список изменений
Для отслеживания изменений в версиях применяются файлы “Логов изменений” ( Changelog ), в которых описываются правки, сгруппированные по версиям. При выпуске новой версии ПО этот файл дополняется соответствующими этой версии изменениями. Каждая группа в этом файле, как правило, состоит из четырех подгрупп:
Взгляните на этот файл на примере пакета Zend-Diactoros.
Чем отличаются версии друг от друга или политика версионирования Alto CMS
Подготовка к обновлению
Этот шаг не обязательный, но желательный, если вы его еще не делали — скопировать файлы конфигурации сайта и все файлы конфигурации всех плагинов и скинов в папку /app вашего сайта.
Если вы что-то меняли в файле /common/config/config.php, то перенесите эти изменения в файл /app/config/config.local.php, и в дальнейшем менять нужно только его. То же касается файлов menu.php, widgets.php и прочих из /common/config/ — не нужно их трогать, делайте копию в /app/config/ и там уже меняйте, все, что нужно.
То же касается и конфигурации плагинов и скинов: например, конфигурацию плагина Topicintro, который вы настраиваете для себя, можно держать в файле /app/plugins/topicintro/config/config.php. А измененную под себя конфигурацию скина Experience — в файле /app/templates/skin/experience/settings/config/config.php. И т.д., и т.п.
Конечно, это не обязательное условие, просто имея копии конфиг-фалов в папке /app/ вы исключаете вероятность того, что однажды случайно их затрете во время очередного обновления движка, плагинов или шаблонов.
Само обновление
Минорная версия — она отличается от фикс-версии тем, что, кроме значительных улучшений функционала, у нее (по сравнению с предыдущей минорной версией) может изменится структура папок и/или структура базы данных. Например, обновление
Подготовка к обновлению
Этот шаг не обязательный, но желательный, если вы его еще не делали — скопировать файлы конфигурации сайта и все файлы конфигурации всех плагинов и скинов в папку /app вашего сайта.
Если вы что-то меняли в файле /common/config/config.php, то перенесите эти изменения в файл /app/config/config.local.php, и в дальнейшем менять нужно только его. То же касается файлов menu.php, widgets.php и прочих из /common/config/ — не нужно их трогать, делайте копию в /app/config/ и там уже меняйте, все, что нужно.
То же касается и конфигурации плагинов и скинов: например, конфигурацию плагина Topicintro, который вы настраиваете для себя, можно держать в файле /app/plugins/topicintro/config/config.php. А измененную под себя конфигурацию скина Experience — в файле /app/templates/skin/experience/settings/config/config.php. И т.д., и т.п.
Конечно, это не обязательное условие, просто имея копии конфиг-фалов в папке /app/ вы исключаете вероятность того, что однажды случайно их затрете во время очередного обновления движка, плагинов или шаблонов.
Само обновление
Изменения структуры базы данных, как правило, записываются в виде SQL-команд в файлах в виде install/db/convert_AAA_to_BBB.sql, где AAA — это номер старой минорной версии, а BBB — номер новой минорной версии. Например:
install/db/convert_0.9.7_to_1.0.sql — обновление
Подготовка к обновлению
Этот шаг не обязательный, но желательный, если вы его еще не делали — скопировать файлы конфигурации сайта и все файлы конфигурации всех плагинов и скинов в папку /app вашего сайта.
Если вы что-то меняли в файле /common/config/config.php, то перенесите эти изменения в файл /app/config/config.local.php, и в дальнейшем менять нужно только его. То же касается файлов menu.php, widgets.php и прочих из /common/config/ — не нужно их трогать, делайте копию в /app/config/ и там уже меняйте, все, что нужно.
То же касается и конфигурации плагинов и скинов: например, конфигурацию плагина Topicintro, который вы настраиваете для себя, можно держать в файле /app/plugins/topicintro/config/config.php. А измененную под себя конфигурацию скина Experience — в файле /app/templates/skin/experience/settings/config/config.php. И т.д., и т.п.
Конечно, это не обязательное условие, просто имея копии конфиг-фалов в папке /app/ вы исключаете вероятность того, что однажды случайно их затрете во время очередного обновления движка, плагинов или шаблонов.
Само обновление
Подготовка к обновлению
Этот шаг не обязательный, но желательный, если вы его еще не делали — скопировать файлы конфигурации сайта и все файлы конфигурации всех плагинов и скинов в папку /app вашего сайта.
Если вы что-то меняли в файле /common/config/config.php, то перенесите эти изменения в файл /app/config/config.local.php, и в дальнейшем менять нужно только его. То же касается файлов menu.php, widgets.php и прочих из /common/config/ — не нужно их трогать, делайте копию в /app/config/ и там уже меняйте, все, что нужно.
То же касается и конфигурации плагинов и скинов: например, конфигурацию плагина Topicintro, который вы настраиваете для себя, можно держать в файле /app/plugins/topicintro/config/config.php. А измененную под себя конфигурацию скина Experience — в файле /app/templates/skin/experience/settings/config/config.php. И т.д., и т.п.
Конечно, это не обязательное условие, просто имея копии конфиг-фалов в папке /app/ вы исключаете вероятность того, что однажды случайно их затрете во время очередного обновления движка, плагинов или шаблонов.
Само обновление
Если вы переходите с одной минорной версии на другую (например, с 1.0 на 1.1) вручную, то вам обязательно нужно обновить структуру базы — найдите и выполните соответствующий SQL-скрипт в папке install/db/. Это можно сделать с помощью phpMyAdmin.
Нумерация версий программы
У многих начинающих разработчиков возникает вопрос: как назначать версию своей программы?
Поделюсь своим опытом.
Не буду вдаваться в теорию, тем более, что жестких рамок в данном вопросе нет. В своей практике я встречал много различных вариантов назначения версий программ.
Приведу несколько примеров написания версии:
Разберем каждое значение.
Ревизия (Revision)
Номер ревизии (revision) в системе управления версиями (Version Control System, VCS или Revision Control System). Благодаря ему, можно легко получить исходный код конкретной версии, выгрузив его из хранилища. Как правило, данное значение начинается с 1 с последующим увеличением соответственно номеру ревизии и никогда не обнуляется. В силу того, что значение важно только для разработки, в нумерации программы его часто опускают.
Билд (build)
Иными словами, номер сборки программы. После изменения в коде программы, как правило, проводят сборку программы, т.е. полную компиляцию всех файлов проекта. Как правило, данное значение начинается с 1 с последующим увеличением соответственно номеру сборки. Обнуление сборки либо не проводят никогда, либо при смене мажорной (major) версии. В силу того, что это значение важно только для разработки, в нумерации программы его часто опускают.
Патч или заплатка (patch)
Значение изначально устанавливается в 0 и увеличивается по мере внесения незначительных изменений в программу, например исправление какой-либо ошибки. Обнуляется при смене мажорной или минорной версий.
Минорная версия (minor)
Значение изначально устанавливается в 0 и увеличивается по мере внесения существенных изменений в программу, например, добавления нового функционала в программу. Значение также может повышаться при накоплении мелких изменений (патчей). Обнуляется при смене мажорной версии.
Мажорная версия (major)
Собственно говоря, это и есть версия программы. Значение мажорной версии устанавливается равной 1. Увеличивается данное значение с выходом новой версии, когда происходят значительные переходы в функциональности, например, добавлены новые функции, существенно меняющие возможности программы, изменен интерфейс, переписаны основные алгоритмы и т.п. Значение также может повышаться при накоплении серьезных (минорных) изменений.
Для пред-релизных версий используют значение равное 0, получая номер вида 0.9.*.*
Год.Месяц.День (year.month.day)
Такое назначение версии указывает на дату выхода программы, что удобно для конечного пользователя. Исходя из такой нумерации пользователь может судить о том, как давно вышла конкретная версия программы, и не пора ли проверить обновление. К сожалению, подобная версионность не всегда удобна для разработчиков, особенно когда над проектом работает не один человек.
Кроме указанных позиций, разработчики часто используют буквенные обозначения в номере версии:
alpha — как правило, первая публичная тестовая версия, перед выходом финальной версии. Служит для обкатки и тестирования.
beta — вторая публичная тестовая версия, перед выходом финальной версии. Также служит для тестирования.
RC, RC2 — релиз-кандидат (Relise Candidate) версия, почти готовая к релизу. Служит для окончательной проверки.
final — окончательная (финальная) версия программы. Используется крайне редко, обычно просто опускается.
Какую схему наименования версий использовать решать прежде всего разработчикам, главное, чтобы нумерация была удобна в разработке и понятна конечному пользователю. И это один из тех вопросов, о которых необходимо договариваться в самом начале разработки любого проекта.