Какова логика нумерации версий для разработчиков с открытым исходным кодом, управляющих выпусками программного обеспечения? [closed]

Я думаю, это скорее общий вопрос, на который я нигде не могу найти ответ. Какова логика нумерации версий для разработчиков с открытым исходным кодом, управляющих выпусками программного обеспечения, и есть ли какие-либо правила или рекомендации, которые я могу прочитать. Истоки этого вопроса связаны с тем, что я просматриваю и исследую программное обеспечение на бесчисленных веб-сайтах, которые я хотел бы использовать в своей ОС Ubuntu.

По опыту я узнал, что некоторые сайты намного лучше других объясняют, является ли выпуск стабильным, экспериментальным или обслуживаемым, но эти объяснения не согласуются с какой-либо знакомой мне логикой нумерации версий.

1
задан 10 April 2012 в 02:04

2 ответа

Я думаю, что, вероятно, стоит обратиться к конкретной части нумерации версий этого вопроса. Конечно, существует множество различных моделей разработки и схем управления версиями, используемых в проектах с открытым исходным кодом. Таким образом, нет однозначного ответа, но есть два очень важных для Ubuntu проекта, которые имеют особый способ нумерации версий.

GNOME использует схему управления версиями, где в X.Y.Z

  • «X» - номер основной версии. Это меняется только тогда, когда в проекте произошел значительный перерыв.

  • «Y» является четным числом для стабильных версий и является нечетным числом * для нестабильных версий * s. Например, версия 3.4.1 стабильна, но 3.5.1 нестабильна.

  • «Z» используется в выпусках с нечетными номерами как приращение к выпускам с четными номерами. После создания стабильного релиза он используется для исправления небольших ошибок «точечные релизы».

Ядро Linux использует аналогичную схему управления версиями. Похоже, это лучше всего подходит для проектов с временными выпусками.

0
ответ дан 10 April 2012 в 02:04

Как вы, вероятно, знаете, существует более одной «методологии разработки программного обеспечения».

И конечно, больше, чем один «жизненный цикл».

Некоторые из них являются «Управляемыми безопасностью», некоторые «Управляемыми релизами», некоторые «Управляемыми по срокам», «Управляемыми документацией» и другими ...

Даже если программное обеспечение с открытым исходным кодом или нет, программным обеспечением можно управлять с помощью любой методологии, в соответствии с целью проекта.

Я думаю; Лучше искать методологию проекта (если она есть, конкретную), а затем искать его версию для управления версиями.

Пример: управление проектом осуществляется с помощью модели жизненного цикла водопада. Это означает, что каждый шаг проверен, есть большая работа, и команда разделена на определенные подкоманды. (Это не подходит для Open Source, потому что Water Fall не для непредубежденных людей)

Пример 2. Проект управляется с помощью XP, Agile: это означает, что проект основан на сюжете (функции). Каждая под-версия приносит новые и полностью работоспособные функции в последнюю программу. И каждая версия вносит большие изменения (или может собирать вместе функции, связанные с целями).

0
ответ дан 10 April 2012 в 02:04

Другие вопросы по тегам:

Похожие вопросы: