Ответ 1
Обычный метод, который я видел, это X.Y.Z, что обычно соответствует major.minor.patch:
- Основные номера версий изменяются всякий раз, когда происходит внесение значительных изменений. Например, большое или потенциально несовместимое с изменениями в программном пакете.
- Незначительные номера версий изменяются при вводе новой, второстепенной функции или при развертывании набора более мелких функций.
- Номера патчей изменяются, когда новая версия программного обеспечения предоставляется клиентам. Обычно это относится к небольшим исправлениям ошибок и т.п.
Другие варианты используют номера построений в качестве дополнительного идентификатора. Таким образом, у вас может быть большое количество для X.Y.Z.build, если у вас есть много версий, проверенных между релизами. Я использую пару пакетов, которые идентифицируются по году/месяцу или году/выпуску. Таким образом, выпуск в сентябре 2010 года может быть 2010.9 или 2010.3 для третьего выпуска этого года.
Существует множество вариантов для управления версиями. Все это сводится к личным предпочтениям.
Для "1.3v1.1", который может быть двумя разными внутренними продуктами, что-то, что будет разделяемой библиотекой/кодовой базой, которая отличается от основного продукта; который может указывать версию 1.3 для основного продукта и версию 1.1 внутренней библиотеки/пакета.