SemVer – сокращение от Semantic Versioning. Это стандартный способ версионирования программных продуктов.
Версия выглядит как X.Y.Z – где X – мажорная версия, Y – минорная, Z – версия патча.
• Мажорная увеличивается, если происходят несовместимые изменения пользовательского API – такое обновление сломает программу;
• Минорная увеличивается, если происходят функционально заметные, но совместимые изменения – такое обновление может поменять поведение;
• Патч увеличивается при незаметных для пользователя изменениях – такое обновление может улучшить качество работы.
Примеры:
• Мажорная – из библиотеки была удалена часть функций, некоторые стали принимать другие параметры: 4.3.12 → 5.0.0.
• Минорная – в приложении добавлен новый режим работы, старый остался без изменений: 1.2.1 → 1.3.0.
• Патч – исправлен баг, улучшена производительность, произведен рефакторинг: 1.1.1 → 1.1.2.
Особый смысл имеет мажорная версия 0. До выпуска 1.0.0, продукт считается на этапе начала разработки. Его поведение может быть нестабильным, а совместимость может ломаться.
Maven: Tips & Tricks — Автоматическое версионирование
Вдобавок к трем версиям иногда используется лейбл (метка) сборки – строка после символа — .
Например, 1.2.3-rc – типичное обозначение версии-кандидата в релиз. Лейблы могут делиться точкой на компоненты: 1.2.3-rc.3 – более поздняя версия чем 1.2.3-rc.2 .
Источник: itsobes.ru
Чем отличаются версии друг от друга или политика версионирования Alto CMS
Минорная версия — она отличается от фикс-версии тем, что, кроме значительных улучшений функционала, у нее (по сравнению с предыдущей минорной версией) может изменится структура папок и/или структура базы данных. Например, обновление с версии 0.9.х на 1.0, описываемый здесь, слегка заморочен, т.к. значительно изменилась структура папок.
Изменения структуры базы данных, как правило, записываются в виде SQL-команд в файлах в виде install/db/convert_AAA_to_BBB.sql, где AAA — это номер старой минорной версии, а BBB — номер новой минорной версии. Например:
install/db/convert_0.9.7_to_1.0.sql — обновление базы с 0.9.7 до 1.0
install/db/convert_1.0_to_1.1.sql — обновление базы с 1.0 до 1.1
Если вы переходите с одной минорной версии на другую (например, с 1.0 на 1.1) вручную, то вам обязательно нужно обновить структуру базы — найдите и выполните соответствующий SQL-скрипт в папке install/db/. Это можно сделать с помощью phpMyAdmin.
Мажорная версия — . Ну, что тут сказать, новых мажорных версий у Alto CMS еще не было. Вот когда выйдет Alto CMS v.2.0 — тогда и поговорим о них 🙂
Похожие статьи
Подготовка к обновлению Этот шаг не обязательный, но желательный, если вы его еще не делали — скопировать файлы конфигурации сайта и все файлы конфигурации всех плагинов и скинов в папку /app вашего сайта. Если вы.
Я уже частично затрагивал эту тему здесь. И сейчас хочу прояснить политику команды в отношении исправления ошибок и обновлений как самого движка, так и плагинов.
Версии, SemVer, обновления! Как в этом ориентироваться разработчику и пользователю?
В AltoCMS используется библиотека PHPMailer, в которой была обнаружена критическая уязвимость. В версии Альто 1.1.27 эта библиотека обновлена. Настоятельно рекомендуется обновить движок до версии 1.1.27! Или.
Таки вышел релиз Alto CMS 1.1.23. Каких-то «прорывных» фишек в ней нет, она, главным образом, исправляет ряд обнаруженных ошибок и чуть-чуть добавляет некоторых новых возможностей для разработчиков. Вот список.
А вот еще бы небольшой FAQ на предмет изменений по отношению к LS. Меня интересуют именно API сторона — разбираюсь как плагины писать. И все время разрываюсь — или под LS читать доки, или с Alto разбираться изначально. Вот и хотелось бы знать, какие ничтяки есть в альто и когда имеет смысл их использовать, а когда можно «сохранить совместимость с LS»… Под LS же модуля совместимости с плагинами от альты еще не изобрели? 🙂
Отредактирован: Только что
Пишите под альто, для лс уже есть куча разработчиков. При том плагин совместимости конечно хорошо, но понятно что движки все больше имеют отличий между собой. А следовательно рано или поздно от него придется отказаться… Вроде бы для пользователя штука хорошая, я сам пользуюсь плагинами от лс, но для разработчика это как бы сколняет его не писать под альто, потому что сообщество лс вроде как больше, и вроде как есть этот плагин, если что пусть мол разработчики движка добиваются совместимости…
Отредактирован: Только что
Принцип организации плагинов что в LS, что в Alto одинаков. Но различия, конечно есть:
1) иная структура папок и шаблонов
2) вместо «блоков» используются виджеты.
Если про API (т.е. классы и их методы), то они во многом совпадают.
Подо что лучше писать — вопрос сложный. С одной стороны, под LS 1.x вроде как поздно, а под LS 2.0 — рано. С другой — я думаю, что немало ресурсов под LS 1.х еще долго будет оставаться, а, стало быть, расширения для них будут актуальны.
Если писать плагины под Alto, то под LS они работать почти наверняка не будут. А модуля совместимости Alto->LS точно не будет — нам не надо, разработчикам LS — тоже 🙂
Отредактирован: Только что
в общем то, склоняюсь больше к следованию все таки новому, вместо совместимости… использую 1.1 ветку.
но вот понимания отличий от ЛС нет… я и ЛС то не знаю еще, и в этом смысле было бы здорово чтобы у альты была самостоятельная документация, с развернутыми (даже) идеологическими выкладками… а так, разбираясь, так или иначе натыкаешься на ЛС — забыть бы про него уже тогда 🙂
Источник: altocms.ru
mrakcw / semanticversion.md
Учитывая номер версии МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ , следует увеличивать:
- МАЖОРНУЮ версию, когда сделаны обратно несовместимые изменения API.
- МИНОРНУЮ версию, когда вы добавляете новый функционал, не нарушая обратной совместимости.
- ПАТЧ-версию , когда вы делаете обратно совместимые исправления.
Дополнительные обозначения для предрелизных и билд-метаданных возможны как дополнения к МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ формату.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Footer
You can’t perform that action at this time.
Источник: gist.github.com