Какой метод вы предпочитаете называть релизами программного обеспечения?

Question

Какой метод вы предпочитаете называть ваши версии программного обеспечения? Как Microsoft: альфа - бета - финал - пакет обновления ... Как Google: Gmail бета - бета - бета - бета - :) Как и некоторые программы: 0,2 - 0,3 - 0,9999 ...

Answer 1

Major.Minor.Release.Build

Хотя инкременты выпуска и сборки не должны содержать «критических изменений» (например, иметь другой формат файла для хранения документов), я не совсем уверен, разрешено ли второстепенным релизам.

Значение альфа-, бета-суффиксов для меня:

Альфа / Просмотр: Эй, у меня есть кое-что, что я хочу показать.

Бета: Набор функций завершен, но есть некоторые ошибки.

Release Candidate: Я думаю, что (серьезных) ошибок не осталось.

Финал: Могут быть ошибки, но в какой-то момент мне нужно выпустить; -).

Answer 2

Мы не выпускаем альфа / бета-версию программного обеспечения для наших клиентов. Поэтому мы просто используем:

• x.0 (для основных выпусков, содержащих важные / множество новых функций)
• x.1, x.2 и т. Д. (Для незначительных выпусков, содержащих незначительные новые функции и улучшения)
• x.y.1, x.y.2 и т. Д. (Для исправлений / обновлений)

(где x, y = 1,2, ...)

Answer 3

Microsoft использует нумерацию версий, а также альфа, бета, GA моникеры.

Я думаю, что наименование версии во многом зависит от того, чего вы пытаетесь достичь. Если вы выпускаете что-то для потребления и не пытаетесь собрать данные за период бета-тестирования, не называйте это бета-тестированием. Если вы не пытаетесь предварительно просмотреть технологию, не называйте ее альфа.

В настоящее время я работаю в основном с веб-приложениями, и мы просто нумеруем наши версии как увеличивающиеся целые числа к моменту развертывания (1, 2, 3, 4, 5 и т. Д.). Нет смысла вдаваться в сложную логику именования, если все равно никто не заботится о версиях.

Answer 4

Я предпочитаю прототип, альфа, бета, метод GA. Это позволяет мне сообщать текущее состояние программного обеспечения пользователям / клиентам. Вместе с этим я предоставляю номера версий .2, .3, .4.

• Первая цифра, обозначающая основные вехи.
• Вторая цифра обозначает увеличение выпуска (обычно я выпускаю раз в неделю, поэтому увеличиваю вторую цифру).
• Третья цифра используется для исправлений, поэтому, если в коде есть ошибка, исправленная за пределами обычного графика выпуска, я использую третью цифру.

Answer 5

Я предпочитаю нотацию ядра Linux: major.minor.release.build, но я редко использую часть .build, и я не использую четные / нечетные числа для стабильных / младших версий разработки.

Answer 6

Некоторые названия проектов с открытым исходным кодом выпускаются после даты их выпуска. Например, Ubuntu 8.04 была выпущена в апреле 2008 года, а Ubuntu 6.06 была выпущена в июне 2006 года. Но Ubuntu - не единственный дистрибутив Linux, использующий этот метод.

Конечно, каждый выпуск Ubuntu также имеет кодовое имя, которое каждый раз является различным животным, в сочетании с аллитерирующим прилагательным (прилагательное также служит приятным сокращением для инсайдеров). Каждый релиз идет вверх по алфавиту, чтобы люди могли легко запомнить, где разместить релиз в устойчивом потоке. Например:

Например 6.06, бледный селезень 6.10, острый эфт 7.04, злющий палевый 7.10, бесстрашный гиббон ​​

Answer 7

То, как мы называли наши релизы, обычно является номером фазы. Поскольку большинство наших контрактов являются государственными проектами, мы выполним первый выпуск, а затем выполним этап 2, этап 3, этап 4, когда организация решит перейти с новыми запросами функций (и получит финансирование для указанных будущих разработок).

Answer 8

Для небольших программ просто Major.Minor. Если основные изменения - некоторые входные файлы не совместимы с предыдущей версией. Мы не выпускаем программное обеспечение для клиентов, поэтому одна и та же версия предназначена для тестирования и окончательного выпуска.