Как называется финальная версия по
Что такое альфа- и бета-версии
Иногда тестировщики — это мы с вами
Каждая программа перед тем, как попасть к пользователю, проходит несколько этапов тестирования. Но иногда пользователям могут быть доступны даже те версии, которые не протестированы до конца — и многие этому даже рады. Давайте разберёмся, как это работает.
Стадии тестирования и разработки софта
Если не углубляться в нюансы разработки и тестирования, то обычно говорят о пяти состояниях, в которых находится программа:
В теории софт должен пройти все стадии, прежде чем отправиться к пользователю. Но на практике бывает так, что люди годами могут пользоваться альфа-версией и это их устраивает. Или даже ждать выпуска преальфы, чтобы скорее воспользоваться новыми возможностями или получить эксклюзивный игровой контент. Всё зависит от целей и задачи программы (или игры).
Преальфа
Преальфа — это сырой продукт, не предназначенный для использования. На нём чаще всего тестируют гипотезы и убеждаются, что софт в принципе может работать.
Эта версия позволяет оценить выбранную архитектуру и подход к программированию, сравнить с планируемой нагрузкой и понять, идёт ли всё по плану или впереди будет гораздо сложнее. В преальфе много ошибок, заглушек и не предусмотренных тестами ситуаций.
Иногда преальфа нужна для того, чтобы показать клиентам или инвесторам, как вообще идут дела в компании. Например, в игровой индустрии ролики из преальфа-версии позволяют заранее прикинуть возможности графики в игре или понять, стоит вкладывать деньги в эту идею или она провалится в прокате.
Альфа
Когда программа доходит до стадии «альфа», то считается, что в ней реализованы все возможности, предусмотренные этой версией, и теперь нужно найти все ошибки.
Случается такое, что во время тестирования в программу добавляются или в ней сокращаются некоторые модули, чтобы снизить сложность или количество ошибок. Альфа-версия считается уже как бы рабочей, но очень сырой версией программы. По идее, ей уже можно пользоваться, но с поправкой на общую глючность.
Бывает такое, что программа в стадии альфа-версии может находиться годами: разработчики никуда не спешат и делают софт для себя. Или у них внезапно закончились деньги, а забрасывать программу жалко. Тогда они могут открыть эту версию для всех, но с оговоркой, что это альфа и что пользуемся на свой страх и риск.
Бета-версия — это уже серьёзно. Чаще всего это означает, что в ней исправлены почти все большие ошибки, но может остаться много мелких, которые ещё не нашли тестировщики.
Компания может выпустить бета-версию программы и для обычных пользователей. Например, она может давать к ней доступ в обмен на сообщения об ошибках — так пользователи раньше остальных получают новый продукт, а компания — бесплатных тестировщиков. Такой процесс тестирования называется открытым, потому что продукт открывается для всех желающих.
Ещё одна причина выпуска бета-версий в свет — желание компании уйти от ответственности за ошибки. Идея такая: компания говорит, мол, что это ещё не окончательная версия, поэтому в ней могут быть баги, которые ещё не отловили. Но на самом деле эту версию никто не будет дорабатывать до финала — в лучшем случае поправят пару заметных ошибок.
Релиз-кандидат
После бета-тестирования и исправления почти всех найденных ошибок, программа переходит в стадию релиз-кандидата. Это значит, что ей можно пользоваться как полноценной программой, но не факт, что тестировщики нашли все ошибки.
Если через 1–3 месяца полноценного использования и тестирования программы в ней не найдут никаких ошибок, программа переходит в стадию релиза.
Релиз-кандидат — это почти всегда та же самая программа, что и в релизе, просто разработчикам нужно убедиться, что она работает стабильно и без сбоёв.
Релиз
Релиз — это готовая версия программы, доступная для всех пользователей.
Релизом может быть и крупное обновление, например, новая версия Windows, а может быть и обновление с версии 1.5.234 на версию 1.5.235. Про то, что означают эти цифры и как они меняются, мы поговорим как-нибудь отдельно.
Что значит альфа и бета версия, RC, релиз?
В сети нам часто попадаются программы с приставками вроде «альфа», «бета» и другими. Давайте рассмотрим, что они означают. Разработка любой программы проходит в несколько этапов. Результатом такой работы на каждом этапе становится какая-нибудь версия ПО. Постепенно программа доводится до стабильного состояния, когда все найденные ошибки исправлены, и она готова к использованию.
Пре-альфа (Pre-Alpha)
Эта приставка присваивается тем версиям программ, которые ещё не вышли в стадию альфа или бета. Тем не менее пре-альфа-программы уже прошли стадию разработки и предоставляются пользователям для оценки их функциональных возможностей. Пре-альфа может содержать далеко не все возможности более поздних версий программы. Так как это «сырая» версия продукта, то неизбежно наличие кучи багов, ошибок и прочих недоработок в программе.
Альфа (Alpha)
Приставка «альфа» присваивается программам, которые тестируются внутри фирмы-разработчика. Альфа-тестирование проводят в основном специалисты-тестеры. Использовать альфа-версии также не рекомендуется, так как в них всё ещё присутствует много ошибок и наверняка неполный функционал. Устанавливать альфа-версии стОит только для ознакомления с будущими возможностями программ.
Бета (Beta)
Бета-версии программ – это уже практически готовые продукты, разработанные в первую очередь для тестирования конечными пользователями. Часто их распространяют бесплатно, чтобы привлечь как можно больше пользователей, и, возможно, потенциальных покупателей будущей платной версии программы. Также благодаря свободному распространению и возможности её использования, у разработчиков появляется возможность получить оценки и отзывы от пользователей. У бета-версий программ также присутствуют ошибки, возможны сбои, так что на пользователя по-прежнему ложится вся ответственность за весь ущерб, который может быть нанесён от использования «беток». Многие разработчики специально затягивают этап бета-тестирования, чтобы избегать таких рисков.
Релиз-кандидат (RC от англ. release candidate)
После альфа и бета-тестирования все возможные ошибки уже устранены и программа практически стабильна. Однако есть ещё вероятность, что обнаружатся баги, поэтому разработчики выпускают программы именно в этой версии – RC. Во многих случаях может выйти несколько версий RC – 1, 2 и т.д.
Релиз (RTM /от англ. release to manufacturing/, Final, Stable)
Это финальная версия программы, готовая к использованию. В ней исправлены практически все ошибки, она обладает полным функционалом, работа её стабильна и протестирована многими пользователями ранее.
Стадии разработки программного обеспечения
В разработке программного обеспечения, стадии разработки программного обеспечения используются для описания степени готовности программного продукта. Также стадия разработки может отражать количество реализованных функций, запланированных для определённой версии программы. Стадии либо могут быть официально объявлены и регламентируются разработчиками, либо иногда этот термин используется неофициально для описания состояния продукта. Следует отметить, что стадии Beta и Alpha (Pre-Alpha) не являются показателями нестабильности релиза так как присваиваются программе один раз или один раз за серию (серией, в данном случае, считается число до первой точки), в зависимости от системы разработки. Они могут присваиваться нескольким релизам подряд. Релизом в данном случае считается завершённая версия (см. Релиз (программное обеспечение)).
Содержание
Этапы разработки
Этапы разработки Milestone — каждому этапу присваивается порядковый номер (1, 2, 3 и т. д.). Например: «Компания сделала продукт, который находится в стадии разработки. Сейчас у него этап разработки Milestone 1.». Это может быть как пре-альфа или бета, так и ранний этап разработки (раньше пре-альфы). Некоторые этапы разработки могут помечаться как «pre-». Например pre-Milestone 1.
Пре-альфа
Начальная стадия разработки — Период времени со старта разработки до выхода стадии Альфа (или до любой другой, если стадии Альфа нет). Также так называются программы, не вышедшие еще в стадию альфа или бета, но прошедшие стадию разработки, для первичной оценки функциональных возможностей в действии. В отличие от альфа и бета версий, пре-альфа может включать в себя не весь спектр функциональных возможностей программы. В этом случае, подразумеваются все действия выполняемые во время проектирования и разработки программы вплоть до тестирования. К таким действиям относятся — разработка дизайна, анализ требований, собственно разработка приложения, а также отладка отдельных модулей.
Альфа
Внутреннее тестирование — Стадия начала тестирования программы в целом специалистами-тестерами, обычно не разработчиками программного продукта, но, как правило, внутри организации или сообществе разрабатывающих продукт. Также это может быть стадия добавления новых функциональных возможностей. Программы на данной стадии могут применяться только для ознакомления с будущими возможностями.
Публичное тестирование — Стадия активного бета-тестирования и отладки программы, прошедшей альфа-тестирование (если таковое было). Программы этого уровня могут быть использованы другими разработчиками программного обеспечения для испытания совместимости. Тем не менее, программы этого этапа могут содержать достаточно большое количество ошибок.
Поскольку бета-продукт не является финальной версией, и публичное тестирование производится на страх и риск пользователя, производитель не несёт никакой ответственности за ущерб, причинённый в результате использования бета-версии. Таким образом, многие производители уходят от ответственности, предоставляя пользователям только бета-версии продукта. Так, ICQ в версии 2003 года использовала этот трюк, выпустив 2003b (b означает бета) версию этого интернет-мессенджера. Финальной версии ICQ 2003 так и не появилось, вместо этого два года спустя вышли версии ICQ 4 и ICQ 5.
Beta Escrow
Стадия бета-тестирования, релиз-кандидат на Beta.
Релиз-кандидат
Релиз-кандидат или RC (англ. release candidate ), Пре-релиз или Pre — стадия-кандидат на то, чтобы стать стабильной. Программы этой стадии прошли комплексное тестирование, благодаря чему были исправлены все найденные критические ошибки. Но в то же время существует вероятность выявления ещё некоторого числа ошибок, не замеченных при тестировании.
RC Escrow
Релиз, который готов получить звание релиз-кандидата. В этом релизе могут быть ещё ошибки.
Релиз
Релиз или RTM (англ. release to manufacturing промышленное издание) — издание продукта, готового к тиражированию. Это стабильная версия программы, прошедшая все предыдущие стадии, в которых исправлены основные ошибки, но существует вероятность появления новых, ранее не замеченных, ошибок. RTM предшествует общей доступности (GA), когда продукт выпущен для общественности.
RTM Escrow
Последний этап разработки продукта, который готов стать RTM-релизом.
Пост-релиз
Пост-релиз или Post-RTM (англ. post-release to manufacturing ), издание продукта, у которого есть несколько отличий от RTM и помечается как самая первая стадия разработки следующего продукта. Такие релизы не выпускаются на продажу, а раздаются бета-тестировщикам. Это издание может быть либо стабильным (если не замечено ошибок), либо с ошибками.
Общая доступность
См. также
Ссылки
Кент Бек • Гради Буч • Фред Брукс • Barry Boehm • Уорд Каннингем • Оле-Йохан Даль • Том Демарко • Эдсгер Вибе Дейкстра • Дональд Кнут • Мартин Фаулер • Чарльз Энтони Ричард Хоар • Watts Humphrey • Майкл Джексон • Ивар Якобсон • Craig Larman • James Martin • Мейер Бертран • Дэвид Парнас • Winston W. Royce • James Rumbaugh • Никлаус Вирт • Эдвард Йордан • Стив Макконнелл
Моделирование данных • Архитектура ПО • Функциональная спецификация • Язык моделирования • Парадигма • Методология • Процесс разработки • Качество • Обеспечение качества • Структурный анализ)
CMM • CMMI • Данных • Function model • IDEF • Информационная • Metamodeling • Object model • View model • UML
Полезное
Смотреть что такое «Стадии разработки программного обеспечения» в других словарях:
Цикл разработки программного обеспечения — Эта статья предлагается к удалению. Пояснение причин и соответствующее обсуждение вы можете найти на странице Википедия:К удалению/30 июля 2012. Пока процесс обсуждения … Википедия
Процесс разработки программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • … Википедия
Управление разработкой программного обеспечения — (англ. Software project management) особый вид управления проектами, в рамках которого происходит планирование, отслеживание и контроль за проектами по разработке программного обеспечения. Ключевым моментом в управлении проектом по… … Википедия
жизненный цикл программного обеспечения — 3.7 жизненный цикл программного обеспечения; жизненный цикл ПО (software lifecycle): Последовательность следующих друг за другом процессов создания и использования программного обеспечения программируемой связанной с безопасностью здания или… … Словарь-справочник терминов нормативно-технической документации
Бережливая разработка программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
жизненный цикл программного обеспечения — … Справочник технического переводчика
Нумерация версий программного обеспечения — Наиболее распространённый в настоящее время способ нумерации версий Жизненный цикл успешной компьютерной программы может быть очень долгим; изменения в программе бывают разными от исправления ошибки до полного переписывания. В бол … Википедия
Жизненный цикл программного обеспечения — (ПО) период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации[1]. Этот цикл процесс построения и развития ПО. Содержание 1 Стандарты… … Википедия
Стресс-тестирование программного обеспечения — Стресс тестирование (англ. Stress Testing) один из видов тестирования программного обеспечения, которое оценивает надёжность и устойчивость системы в условиях превышения пределов нормального функционирования. Стресс тестирование особенно… … Википедия
Аспектно-ориентированная разработка программного обеспечения — В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете … Википедия
Релиз
Релиз (англ. Release) – подразумевает под собой последний выпуск программного обеспечения, это самая новая версия программного обеспечения, содержащая все изменения и обновления. В релизе содержатся новые и измененные конфигурационные единицы, в отношении которых осуществлено тестирование и которые готовы к использованию. Целью процесса управления релизами является консолидация, структурирование и оптимизация всех изменений или обновлений ПО. Также при этом снижаются риски при переходе продукта на новый качественный уровень.
Содержание
Общие сведения
Общую информацию Вы можете получить, перейдя по следующим ссылкам:
Расширенные сведения
С дополнительной информацией об этом понятии Вы можете ознакомиться ниже.
У релиза программного обеспечения есть свой жизненный цикл (см. иллюстрацию):
Пре-альфа
Первый этап жизненного цикла релиза ПО называется «Пре-альфа» (англ. Pre-alpha). Пре-альфа относится ко всем видам деятельности на этапе разработки ПО до момента тестирования. На этом этапе выполняют такие действия:
Альфа
Третий этап – «Бета» (англ. Beta). Данный этап, как правило, начинается с завершения разработки всех функций ПО. На этапе Бета в программах находят больше технических деффектов, чем на предыдущих этапах (например, скорость работы или производительность системы). Этот этап предполагает проведение тестирования эксплуатационной пригодности. Процесс предоставления пользователям бета-версии программы называется Бета-релиз. По сути, это тот этап, когда программное обеспечение становится доступным для внешних пользователей, а не только для разработчиков внутри организации.
Закрытое и открытое Бета-тестирование
Четвертый этап – «Закрытое и открытое Бета-тестирование». То есть разработчики выпускают или закрытую версию ПО, или открытую. Закрытая Бета-версия программы доступна лишь для узкого круга пользователей, которые протестируют ПО. Соответственно, открытая Бета-версия доступна широкому кругу лиц, которые могут протестировать программу по своей инициативе. После чего, они сообщают разработчикам о возникших ошибках и иногда предлагают дополнить программу какими-то функциями, которые, по их мнению, должны присутствовать в финальной версии программы. Примерами основных открытых бета-версий программ могут служить:
Тестирование открытых Бета-версий применимо в двух случаях:
Пятый этап называется «Релиз-кандидат» (англ. Release candidate, RC)- это Бета-версия продукта, который имеет достаточно потенциала для того, чтобы стать финальной версий. На этом этапе продукт станет финальным релизом, в случае, если не возникнут серьезные дефекты. На данном этапе происходит стабилизация функционирования ПО – все функции разработаны, закодированы и протестированы. Этот релиз превращается в релиз с утвержденным кодом (code complete), когда вся команда разработчиков убеждена, что ни один новый код не будет добавлен в данную программу.
Релиз для производства
Шестой этап называется «Релиз для производства» (англ. «Release to manufacturing,RTM). Термин RTM, известный также, как «становящийся золотом»(англ. Going Gold), используется, когда продукт может предоставляться конечным пользователям. Чаще всего, подразумеваются розничные продажи широкому числу покупателей. Термин RTM также может означать, что продукт был предоставлен клиентам для инсталляции на своих аппаратных устройствах. Этот термин не определяет способ и объем доставки ПО потребителям, он всего лишь указывает на то, что на этом этапе качества продукта достаточно для массового распространения. Этот этап предшествует этапу жизненного цикла релиза ПО под названием «Общедоступный Релиз».
Общедоступный Релиз
Веб-релиз
Окончание срока службы
Завершающий этап «Окончание срока службы» (англ. End-of-life). Означает, что программа больше не продается и не поддерживается. ПО морально устаревает, но иногда лояльность пользователей может продлить программе жизнь на еще какой-то промежуток времени.
Software versioning
Методология изменения версий продукта программного обеспечения
Software versioning — это процесс создания уникальных имен или номеров для различных версий продуктов программного обеспечения.
При имеющейся категории номера версии (главная, второстепенная), номера обычно выставляются в возрастающем порядке и соответствуют новым разработкам в программном обеспечении. На начальном уровне отслеживанием постепенно появляющихся версий электронной информации занимается система управления версиями, позволяющая хранить несколько версий одного и того же документа, при необходимости, возвращаться к более ранним версиям, определяя, кто и когда сделал то или иное изменение и многое другое. Вместе с тем для отслеживания изменений программного обеспечения было создано большое количество схем присвоения номеров версиям.
Каждой стадии разработки программного обеспечения соответствует уникальный идентификатор, который состоит из последовательности номеров или букв. В некоторых схемах последовательные идентификаторы используются для определения значимости перемен между стадиями разработки: эти перемены классифицируются по уровням значимости. Решение о том какую последовательность изменить между стадиями разработки основано на значимости перемен на последней стадии разработки, например в схеме, с версией, состоящей из последовательности 4 чисел, первое число может быть прибавлено только тогда когда код полностью переписан, в то время как четвертое число изменяется при незначительных переменах в интерфейсе или документации.
В более поздних релизах, главное число (major) увеличивается, когда происходят значительные переходы в функциональности, второстепенное число (minor) прибавляется только тогда, когда были добавлены незначительные функции или внесены исправления. Номер версии изменяется, если исправлены все мелкие неполадки. Для типичного программного продукта используются следующие номера: 0.9 (для бета-версии), 0.9.1, 0.9.2, 0.9.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.1.1, 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.2, 2.2, и т.д. Разработчики порой перескакивают от версии 5.0 сразу к 5.5, для того чтобы обозначить добавление нескольких значимых функций в программе, однако их не достаточно, чтобы изменить главный номер версии, тем не менее такие скачки все же неуместны.
Другой подход использования главных и второстепенных номеров версий заключается в добавлении буквенно-цифровой последовательности, определяя тем самым стадию разработки релиза: «альфа», «бета», «релиз кандидат». Серия версий с использованием этого подхода может выглядеть следующим образом: если к версиям 0.5, 0.6, 0.7, 0.8, 0.9 добавляются новые функции их можно назвать — 1.0b1, 1.0b2, еще плюс новые функции — 1.0b3, затем версия становится 1.0rc1. Если версия 1.0rc1 достаточно стабильна, то она становится 1.0, однако если в 1.0rc1 обнаруживаются ошибки, которые необходимо исправить она будет иметь номер 1.0rc2 и т.д. Важной характеристикой этого подхода является соблюдение идентичности стадий разработки версий. Нельзя вносить никаких изменений между последней бета-версией и первым релиз кандидатом или последним релиз кандидатом и готовым продуктом. Если вы это сделали, необходимо выпустить другую версию на более низкой стадии разработки.
Известные примеры буквенно-цифровых версий — Macromedia Flash MX, Adobe Photoshop CS2.
Иногда присутствие человеческого фактора в создании номеров версий приводит к ошибкам в изменении версий. Например, разработчики могут изменить последовательность между версиями, даже если одна строчка кода не была переписана, лишь для того чтобы создать ложное впечатление, что были внесены значительные изменения.
Обозначение стадии разработки
Для присвоения альфа или бета статуса релизам, которые еще не достаточно стабильны для практического применения, существуют схемы, где в первой последовательности используется ноль. Он ставится третьим числом в тех случаях, когда планируется еще тестировать версию или версия годна только для внутреннего применения.
Разделение последовательностей
При публикации последовательности могут быть разделены знаками препинания. Выбор знаков препинания и их использования зависит от схемы.
Номера последовательностей
Приращение последовательности
Существует два разных способа приращения последовательности номеров в версии. Большинство продуктов свободного программного обеспечения используют непрекращаемый поток последовательных номеров: 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2, и т.д. Примером такого продукта может служить MediaWiki. В других программах используются десятичные номера: 1.7, 1.8, 1.81, 1.82, 1.9, и т.д. В таких программах после версии 1.8 будет идти версия 1.81, текущие релизы будут обозначаться 1.81a, 1.81b, и т.д.
Использование дат в версиях
Разработчики проекта Wine использовали даты при нумерации версий, они указывали год, месяц и день релиза: «Wine 20040505». Сейчас Wine использует «стандартную» нумерацию релизов, последняя версия 2010 года имеет номер 1.2. Компания Ubuntu Linux использует похожую схему нумерации, например релиз апреля 2010 года пронумерован как Ubuntu 10.04. Номера сборок Microsoft Office тоже на самом деле закодированные даты.
Здесь следует отметить, что при использовании дат в нумерации версий необходимо использовать схему ISO, то есть сначала указывается год, затем месяц, а потом день (YYYY-MM-DD), причем дефис можно опускать.
Существуют также примеры нумерации версии годом выпуска (Adobe Illustrator 88, WordPerfect Office 2003). Хотя такой ход чаще всего используется в маркетинговых целях, и настоящий номер версии все равно существует. Например, версия Microsoft Windows 2000 Server на самом деле имеет номер Windows NT 5.0.
Схема нумерации версий TeX
Система TeX использует уникальную схему нумерации версий. После появления версии номер 3, ко всем последующим обновленным версиям после точки добавляли цифру, соответствующую последовательности числа Π это одна из форм унарной системы счисления – номер версии соответствует номеру цифры в числе Π. Номер последней версии 3.1415926. Такой метод отражает стабильность системы TeX. Разработчик TeX Дональд Кнут сказал, что последняя версия выйдет после его смерти и ее номер будет полное число Π, в которой все оставшиеся недочеты станут постоянными функциями. Подобной схемы придерживается METAFONT, нумеруя версии числами из математической константы e.
Схема Apple
,Apple использует формализованную структуру нумерации версий основанную на структуре NumVersion, она состоит из номера главной версии (1-2 числа), номера второстепенной версии (1 число), номера исправленной версии («bug» version) (1 число), индикатора стадии разработки (преальфа, альфа, бета и т.д.) и номера пререлиза (0-255). При написании этих номеров версий в строке, существовало условное соглашение опускать часть номера, обозначающую нулевую или последнюю стадию разработки. На пример: 1.0.2b12, 1.0.2 (вместо 1.0.2f0), и 1.1 (вместо 1.1.0f0).
Другие схемы
Производители программного обеспечения используют различные схемы для обозначения релиза их софта. Например, операционная система Microsoft Windows появилась на рынке со стандартной числовой схемой обозначения версий (от Windows 1.0 до Windows 3.11). Позднее разработчики Microsoft начали разделять названия версий в маркетинговых целях, то есть, сначала используя год релиза (Windows 95 (4.0), Windows 98 (4.10), Windows 2000 (5.0)), потом буквенно-цифровые коды (Windows Me (4.90), Windows XP (5.1)), после чего названия брендов (Windows Vista (6.0)). Судя по последнему релизу Windows 7, Microsoft снова вернулся к стандартной числовой схеме, хотя официальное название версии Windows 7 это 6.1.
В проекте Debian для релизов операционной системы используется «major/minor» схема, а для названий программных продуктов при разработке используются имена из мультфильма «История Игрушек».
Скрытые номера версий
Продукт программного обеспечения может иметь так называемый «скрытый» номер версии, который не указан в основном названии продукта (обычно в составлении скрытого номера соблюдаются все правила нумерации версий). Например, версия Java SE 5.0 имеет внутренний номер 1.5.0, а версии Windows начиная от NT 4, продолжают внутреннюю стандартную нумерацию версий: Windows 2000 это NT 5.0, XP это Windows NT 5.1, 2003 это NT 5.2, Vista это NT 6.0 и 7 это NT 6.1.
Предварительные версии продуктов программного обеспечения
Вместе с различными схемами обозначения версий, перечисленными выше, система, обозначающая предварительные версии используется в большинстве случаев как программа, прокладывающая себе путь через все стадии разработки программного обеспечения. Программы, находящиеся на ранних стадиях разработки называются «альфа» (первая буква греческого алфавита). Более зрелые программы, но еще не готовые к релизу называются «бета» (вторая буква греческого алфавита). В основном продукты программного обеспечения «альфа» тестируются только разработчиками, в то время как продуты «бета» распространяются на публичное тестирование. Этим двум версиям продукта обычно присваивается номер меньше 1, например 0.9, так как 1.0. это уже для публичного релиза. Однако если создается предварительная версия к уже существующему продукту, то она может быть обозначена буквой «а» (значит альфа) добавленной к номеру версии готового продукта, например версия 2.5 – предварительная версия 2.5.а или 2.5а. Продукты готовые к релизу могут быть обозначены тегом «rc-#», что означает релиз кандидат (release candidate). Когда версия уже выпущена, тег убирается.
Нечетные числа в обозначении версий для разработки релиза
Между сериями 1.0 и 2.6.x, Linux kernel использовал нечетную нумерацию версий, что бы обозначить релизы в разработке, а для стабильных релизов четную нумерацию. Например Linux 2.3 была серия разработок второго главного дизайна Linux kernel, а Linux 2.4 была серия стабильных релизов, в которую перерос Linux 2.3. В номере релиза Linux kernel сначала писался номер второстепенной версии, а затем номер релиза в возрастающем порядке. Например Linux 2.4.0 → Linux 2.4.22. После релиза 2.6 kernel в 2004 году, Linux больше не использует эту систему, теперь цикл релиза намного короче. Сейчас они просто увеличивают третье число, используя четвертое при необходимости.
Apple и нечетные числа
У компании Apple были свои особенности на счет нечетных чисел, особенно во время системы MacOS. Даже тогда когда выпускались второстепенные (minor) релизы номер версии редко был больше чем 1, а если номер нужно было увеличить они перескакивали сразу на 5, предлагая при этом небольшое изменение величины между главным и второстепенным релизом (например, 8.5 значит «восемь с половиной», а 8.6 значит «восемь с половиной точка один»). Завершенная последовательность версий выглядит так: 1.0, 1.1, 2.0, 2.1, 3.0, 3.2 (3.1 пропущена), 4.0, 4.1, 5.0, 5.1, 6.0, 7.0, 7.1, 7.5, 7.6, 8.0, 8.1, 8.5, 8.6, 9.0, 9.1, 9.2.
Версия 1.0 как ключевой этап разработки
Разработчики проприетарного программного обеспечения всегда называют первый релиз программы версия 1, а затем увеличивают номер главной версии после каждого переписывания кода. Это значит, что программа может достичь версии 3 всего за несколько месяцев разработки, при этом она еще возможно не станет стабильной и надежной.
В отличие от компаний, сообщество свободного программного обеспечения используют версию 1.0 как ключевой этап разработки, обозначая тем самым, что продукт завершен, в нем есть все необходимые функции, и он достаточно надежен для публичного использования.
Согласно этой схеме, номер версии медленно приближается к 1.0 пока устраняются все недочеты в подготовке к релизу. Разработчики MAME, например, не стремятся выпускать версию 1.0 программы эмулятора, аргументируя это тем, что она никогда не будет до конца завершена, потому что аркадные игры будут появляться всегда. За версией 0.99 просто следует версия 0.100. Подобный пример Xfire, после релиза 1.99 идет 1.100. Так за 6 лет существования eMule все еще не достигли версии 0.50.
История программ
Winamp выпустил совершенно иную конфигурацию третьей версии программы, в которой отсутствовала обратная совместимость с плагинами и другими ресурсами предыдущей версии. Однако, эта версия стала полностью совместимой с версиями 2 и 3, но нумеровалась пятой, то есть 4 была пропущена… То же самое произошло с UnixWare 7, что было соединением UnixWare 2 и Open Server 5.
Как не отставать от конкурентов
В индустрии проприетарного программного обеспечения существует общая привычка перескакивать в нумерации главных и второстепенных версий в маркетинговых целях.
Это можно увидеть на примере нескольких продуктов Microsoft и America Online, а также в системе нумерации версий Sun Solaris, Java Virtual Machine, в версиях SCO Unix и Corel Word Perfect. Программные продукты filePro DB/RAD имели нумерацию от 2.0 к 3.0 к 4.0 к 4.1 к 4.5 к 4.8 к 5.0, и они уже готовят релиз 5.6, не имея при это ни одного промежуточного. Небольшую разницу можно заметить между версиями программного обеспечения AOL’s PC client, хотя они нумеруют только главные релизы — 5.0, 6.0, 7.0, и т.д. Таким же образом Microsoft Access перескочили от версии 2.0 к версии 7.0, чтобы догнать нумерацию версий Microsoft Word.
У корпорации Microsoft тоже была цель догнать нумерацию версий браузера Netscape, пропустив версию 5 и выпустив сразу шестую версию Internet Explorer.
Суеверия
У релиза 2007 программы Microsoft Office был внутренний номер версии 12. Релиз Office 2010 внутренне нумеровался уже 14, из-за плохой репутации чертовой дюжины.
Версия 13 WordPerfect Office программы Corel обозначена в продаже как «X3» (римская цифра 10 и «3»). Процедура повторилась в следующей версии X4.
Как преодолеть маркетинговые трудности
В середине 1990х быстро развивающиеся на китайском рынке CMMS и Maximo, перескакивали от версии Maximo Series 3 сразу к Series 5, пропуская Series 4, так как неправильное произношение номера 4 на китайском языке могло означать «смерть» или «неудача». Хотя это, однако, не остановило Maximo Series 5 при выпуске релиза 4.0. Следует отметить, что на этом нумерация Series остановилась, но возобновилась вполне успешно, начиная с релиза 1.0.
Значимость нумерации версий в разработке программного обеспечения
Номера версий используются в практических условиях потребителем или клиентом для того, чтобы можно было сравнить имеющуюся у них копию продукта программного обеспечения и новую версию, выпущенную разработчиком. Команда программистов и компании используют нумерацию версий для сравнения отдельных частей и секторов программного кода одних версий с другими, обычно сотрудничая с Системой контроля версий. Не существует абсолютной и определенной схемы нумерации версий продуктов программного обеспечения, поэтому очень часто нумерация зависит от личного выбора программистов.
Перевод осуществлен сотрудницей компании «Chyrius» Натальей Володиной.