Я всё в интернете ищу и не как не могу найти где написано ка обозначать версию программы. Где-то пишут так 1.0.0.0 а где-то 1.00 или 0.01. Так как правильно? Например у меня вышла первая версия программы. Как это записать?
0.01?
Регистрация: 13.12.2006
Сообщений: 3,859
каждый выбирает сам для себя принцип нумерования версий.
Если у вас приложение состоит из одноо файла и не является сложным проектом, до достаточно обходится 2-х, 3-х актетовым нумерованием. Первая версия обычно в этом случае обозначается 0.0.1 или 0.1
Первый актет меняется в случае координальных изменений в программе. В случае только исправлений ошибок (если их не очень много), то меняется только билд.
ICQ не для вопросов, а для предложений. Для вопросов используйте форум
IRC канал клуба программистов | Мои статьи
Форумчанин
Регистрация: 18.06.2008
Сообщений: 277
Квэнди, спасибо за информацию. А вот если у меня программа из нескольких файлов и большевата, то как тогда, вот так — 0.0.0.1?
Версия Файла несовместима с используемой версией Windows — решение
Регистрация: 13.12.2006
Сообщений: 3,859
все зависит от того что у тебя меняется от версии к версии. Если ты используешь кучу своих DLL, и иже с ними,и в обновлениях частенько их обновляешь, то лучше увеличить нумерацию версий на один- максимум 2 актета. В любом случае лучше не использовать больше 4-х актетов в сумме, мелкие изменения отображай билдом.
ICQ не для вопросов, а для предложений. Для вопросов используйте форум
IRC канал клуба программистов | Мои статьи
Источник: www.programmersforum.ru
Управление версиями программного обеспечения
Управление версиями обновления программного обеспечения — это процесс присвоения либо уникальных имен версий, либо уникальные номера версий для уникальных состояний компьютерного программного обеспечения. В рамках данной категории номера версии (основной, дополнительный) эти номера обычно присваиваются в порядке возрастания и соответствуют новым разработкам в программном обеспечении. На мелкомасштабном уровне контроль версий часто используется для отслеживания постепенно изменяющихся версий информации, независимо от того, является ли эта информация компьютерным программным обеспечением.
Современное компьютерное программное обеспечение часто отслеживается с использованием двух разных схем управления версиями программного обеспечения — внутренний номер версии, который может многократно увеличиваться в течение одного дня, например, контрольный номер версии, и версия выпуска которые обычно меняются гораздо реже, например, семантическое управление версиями или кодовое имя проекта.
Схемы
Для отслеживания разных версий программного обеспечения были созданы различные схемы нумерации версий. Повсеместное распространение компьютеров также привело к тому, что эти схемы использовались вне вычислительной среды.
Идентификаторы на основе последовательностей
В схемах управления версиями программного обеспечения на основе последовательностей каждому выпуску программного обеспечения назначается уникальный идентификатор, который состоит из одной или нескольких последовательностей цифр или букв. Это степень общности; схемы широко различаются в таких областях, как количество последовательностей, приписывание значения отдельным последовательностям и способы увеличения последовательностей.
Скрытая Функция Android 13
Значимость изменений
В некоторых схемах идентификаторы на основе последовательности используются для передачи значимости изменений между выпусками. Изменения классифицируются по уровню значимости, и решение о том, какую последовательность менять между выпусками, основывается на значимости изменений по сравнению с предыдущим выпуском, при этом первая последовательность изменяется для наиболее значительных изменений, а изменения в последовательностях после первого представляют. изменения уменьшающейся значимости.
В зависимости от схемы значимость может быть оценена по измененным строкам кода, добавленным или удаленным функциональным точкам, потенциальному влиянию на клиентов с точки зрения работы, необходимой для принятия новой версии, риску ошибок или необъявленных критических изменений, степень изменений визуального оформления, количество новых функций или почти все, что разработчики продукта или маркетологи считают значительными, включая маркетинговое желание подчеркнуть «относительное качество» новой версии.
Семантическое управление версиями (также известное как SemVer), в настоящее время наиболее известная и наиболее широко используемая схема версий в этой категории, использует последовательность из трех цифр (Major.Minor.Patch), дополнительный тег предварительной версии и дополнительную сборку метатег. В этой схеме мерами значимости являются риск и функциональность. Критические изменения обозначаются увеличением главного номера (высокий риск), новые неразрывные функции увеличивают второстепенное число (средний риск), а все другие неразрывные изменения увеличивают номер исправления (самый низкий риск). Наличие тега перед выпуском (-alpha, -beta) указывает на существенный риск, как и большое число, равное нулю (0.yz), которое используется для обозначения незавершенной работы, которая может содержать любой уровень потенциально критические изменения (самый высокий риск).
Разработчики могут выбрать одновременный переход к нескольким дополнительным версиям, чтобы указать, что были добавлены важные функции, но этого недостаточно, чтобы гарантировать увеличение номера основной версии; например, Internet Explorer 5 от 5.1 до 5.5 или Adobe Photoshop 5 до 5.5. Это может быть сделано для того, чтобы подчеркнуть ценность обновления для пользователя программного обеспечения или, как в случае Adobe, для представления выпуска на полпути между основными версиями (хотя уровни управления версиями на основе последовательности не ограничиваются одной цифрой, как в Blender версии 2.79).
Другой подход — использовать старший и младший номера вместе с буквенно-цифровой строкой, обозначающей тип выпуска, например «альфа» (а), «бета» (б) или «релиз-кандидат» (rc). Цепочка релизов программного обеспечения с использованием этого подхода может выглядеть как 0.5, 0.6, 0.7, 0.8, 0.9 → 1.0b1, 1.0b2 (с некоторыми исправлениями), 1.0b3 (с дополнительными исправлениями) → 1.0rc1 (что, если он достаточно стабилен), 1.0rc2 (если обнаружено больше ошибок) → 1.0. Обычной практикой в этой схеме является блокирование новых функций и критических изменений на этапах выпуска-кандидата, а для некоторых команд даже бета-версии привязаны только к исправлениям ошибок, чтобы обеспечить согласованность с целевым выпуском.
Другие схемы придают значение отдельным последовательностям:
major.minor [.build [.revision]] (пример: 1.2.12.102) major.minor [.main maintenance [.build ]] (пример: 1.4.3.5249)
Опять же, в этих примерах определение того, что составляет «основное», а не «незначительное» изменение, полностью субъективно и зависит от автора, как и то, что определяет « build », или чем« ревизия »отличается от« незначительного »изменения.
Общие библиотеки в Solaris и Linux могут использовать формат current.revision.age, где:
current: самый последний номер интерфейса, который реализует библиотека. revision: номер реализации текущего интерфейса. age: разница между самым новым и самым старым интерфейсами, реализуемыми библиотекой. Такое использование третьего поля характерно для libtool : другие могут использовать другое значение или просто игнорировать его.
Аналогичная проблема относительной значимости изменений и номенклатуры управления версиями существует в книгоиздании, где номера изданий или названия могут быть выбраны на основании различных критериев.
В большинстве проприетарных программ первая выпущенная версия программного продукта имеет версию 1.
Степень совместимости
Семантическое управление версиями, состоящее из трех частей, номер версии
В некоторых проектах используется основной номер версии для обозначения несовместимых выпусков. Два примера: Apache Portable Runtime (APR) и FarCry CMS.
Семантическое управление версиями — это формальное соглашение для определения совместимости с использованием номера версии из трех частей: основная версия; минорная версия; и патч. Номер патча увеличивается для незначительных изменений и исправлений ошибок, которые не изменяют интерфейс прикладного программирования (API) программного обеспечения. Дополнительная версия увеличивается для выпусков, которые добавляют новые, но обратно-совместимые функции API, а основная версия увеличивается для изменений API, которые не имеют обратной совместимости. Например, программное обеспечение, основанное на версии 2.1.5 API, совместимо с версией 2.2.3, но не обязательно с 3.2.4.
Часто программисты пишут новое программное обеспечение для обратной совместимости, т. Е. Новое программное обеспечение предназначено для правильного взаимодействия со старыми версиями программного обеспечения (с использованием старых протоколов и форматов файлов) и самыми последними версия (с использованием новейших протоколов и форматов файлов). Например, IBM z / OS предназначена для правильной работы с тремя последовательными основными версиями операционной системы, работающими в одном сисплексе. Это позволяет людям, использующим компьютерный кластер высокой доступности, поддерживать большую часть компьютеров в рабочем состоянии, пока одна машина будет выключена, обновлена и восстановлена для работы.
Часто заголовки пакетов и формат файла включают номер версии — иногда такой же, как номер версии программного обеспечения, которое его написало; в других случаях «номер версии протокола» независимо от номера версии программного обеспечения. Код для обработки старых устаревших протоколов и форматов файлов часто рассматривается как бесполезный.
Обозначение стадии разработки
Программное обеспечение на экспериментальной стадии (альфа или beta ) часто используют ноль в первой («основной») позиции последовательности для обозначения ее статуса. Однако эта схема полезна только на ранних стадиях, а не для будущих выпусков с установленным программным обеспечением, где номер версии уже превысил 0.
Для обозначения статуса более новой версии используется ряд схем:
- Буквенно-цифровой суффикс — это общая схема, принятая для семантического управления версиями. В этой схеме к версиям добавлен тире и несколько буквенно-цифровых символов для обозначения статуса.
- Числовой статус — это схема, в которой используются числа для обозначения статуса, как если бы он был частью последовательности. Типичный выбор — третья позиция для четырехпозиционного управления версиями.
- Numeric 90+ — это еще одна схема, в которой используются числа, но, очевидно, под номером предыдущей версии. В последней позиции используется большое число, обычно 90 или больше. Это обычно используется более старыми проектами с открытым исходным кодом, такими как GNOME и Fontconfig.
См. Также
- Непрерывная защита данных
- Техническая версия
- Управление жизненным циклом продукта
- Разработка программного обеспечения
Ссылки
ние ссылки
- 3 Эффективные методы для обеспечения Управление версией
- Практическое руководство по выпуску программного обеспечения
- Нумерация версий программного обеспечения
- План выпуска Document Foundation для LibreOffice с указанием следующих выпусков
Источник: alphapedia.ru
Русские Блоги
О значении номеров версий BETA, RC, ALPHA, Release, GA и т. Д.
В последнее время из-за необходимости работы я часто хожу в SVN, чтобы загрузить исходный код проектов с открытым исходным кодом. Я не знаю значения BETA, ALPHA, RC и других номеров версий, стоящих за проектом, поэтому я не знаю, какой каталог подходит. Сейчас я специально искал информацию,
Объясните значение номера версии.
Alpha： Альфа — это внутренняя тестовая версия, обычно не выпускаемая для сторонних разработчиков, в ней будет много ошибок. Если вы не являетесь тестировщиком, ее не рекомендуется использовать. Это первая буква греческого алфавита, обозначающая начальную версию, альфа — это α, бета — это β, Альфа-версия лучше, чем
Бета-версии, которые все еще находятся на ранней стадии бета-тестирования, обычно проходят внутреннее тестирование.
Beta: По сравнению с альфа-версией эта версия была значительно улучшена, и были устранены серьезные ошибки, но все же есть дефект, который необходимо протестировать для дальнейшего устранения. Версия на этом этапе всегда будет добавлять новые функции. RC：(Release Candidate) Кандидат означает кандидата, и это версия кандидата при использовании в программном обеспечении.
Release.Candidate. — это версия кандидата на выпуск. Самая большая разница с бета-версией заключается в том, что новые функции всегда будут добавляться на стадии бета-тестирования, но в версии RC почти
Новые функции добавляться не будут, и основное внимание будет уделяться отладке! Версия RC — это версия, наиболее близкая к официальной версии, которая наконец выпущена для пользователей. После выпуска исправлены ошибки в официальной версии, которая является последней тестовой версией перед официальной версией.
GA：（general availability） Например: Apache Struts 2 GA. Это первая стабильная версия Apache Struts 2. GA означает общедоступность, которая официально рекомендуется для широкого использования. Release: Эта версия означает «окончательная версия» .После серии тестовых версий предыдущей версии, в конечном итоге будет официальная версия, которая наконец будет доставлена пользователям.
Эту версию иногда называют стандартной. В нормальных условиях Release не будет отображаться в виде слова на обложке программного обеспечения, вместо этого это будет символ (R).
Источник: russianblogs.com