VNS. Схема нумерации версий

• 1 Введение
  • 1.1 Что это такое
  • 1.2 Зачем это нужно
  • 1.3 Пример истории проекта
  • 1.4 Взаимодействие с системой cvs
  
  
• 2 Нумерация версий
  • 2.1 Правила формирования символьных меток
  • 2.2 Импорт
  • 2.3 Работа
  • 2.4 Выпуск релиза
  • 2.5 Создание ветки
  • 2.6 Объединение веток
  • 2.7 Переименование файлов
  • 2.8 Удаление файлов
  
  
• Ссылки
• Версия

1 Введение

1.1 Что это такое

Основные идеи схемы нумерации изложены в [1]. Схема основана на Berkeley CSRG с дополнениями из проекта GNU.

Номер версии имеет формат X.YY[.ZZ] , где

• [X:]старший номер релиза. Увеличивается при наличии существенных изменений, которые, в т.ч. могут приводить к потере обратной совместимости

• [YY:]младший номер релиза. Увеличивается при появлении новой или улучшении старой функциональности
• [ZZ:] 
  • [нет]официальный релиз (публичный)
  • [1..69]патч-релизы официального (публичный)
  • [70..90]альфа релиза с YY+1 (только для разработчиков)
  • [90..]бета релиза с YY+1 (для разработчиков и тестеров)

1.2 Зачем это нужно

Руководства по использованию cvs обычно посвящены командам cvs и работе с ними. Вместе с тем вопросы нумерации версий (т.е. какие метки присваивать релизам) считаются вопросом личных предпочтений и практически не затрагиваются. Данный документ и предназначен для описания одного из вариантов таких предпочтений с целью обеспечить стандартный подход к нумерации версий проектов.

1.3 Пример истории проекта

• [Типичная]история версий проекта может иметь вид:
  • [0.0.70] 1й релиз после импорта (альфа версии 0.1)
  • [0.0.71] следующий неофициальный релиз
  • [0.0.80] релиз для тестеров (бета версии 0.1)
  • [0.1] первая публичная версия
  • [0.1.70] первый альфа-релиз версии 0.2
  • [0.1.1] в версии 0.1 обнаружены ошибки и выпущен патч-релиз
  • [0.1.80] первый бета-релиз версии 0.2
  • [0.2] очередная публичная версия
  • [1.0.70] начата работа над официальным релизом 1.1

Релизам не присваиваются номера вида X.0 или X.YY.0. YY не может быть 0 потому. что тогда альфа и бета релизы такой версии имели бы другой (меньший на 1) старший номер релиза, а ZZ=0 - это и есть версия X.YY Т.о. 1.0.70 - первый альфа-релиз 1й официальной версии 1.17; максимальный номер релиза 1й версии - 1.99.69; минимальный номер (т.е. альфа) версии 2 - 2.0.70. Номера релизов в диапазоне 1.99.70 - 2.0.69 не используются.

1.4 Взаимодействие с системой cvs

Использование для хранения номеров релизов проекта внутренней для CVS схемы нумерации ревизий файлов AFAIK не является общепринятой практикой и затруднено по следующим причинам:

• некоторые команды (например, cvs export) вообще не могут работать с не-символьными метками
• в CVS есть всего один способ явно изменить номер ревизии файлов - cvs ci -r X.Y.
• если проект состоит из нескольких каталогов, то при попытке осуществить коммит с указанием номера ревизии, cvs может (за 2 дня поисков я не локализовал причину) прервать работу и сообщить об отсутствии служебной информации cvs в каком-либо подкаталоге.

Поэтому схема основана только на символьных метках. При этом разработка проекта осуществляется на стволе, а при необходимости выпуска патчей к релизам X.YY от точек публикации релизов отводится патч-ветка.

2 Нумерация версий

2.1 Правила формирования символьных меток

vX_YY

Метка ствола, соответствующая версии X.YY. Снимок проекта в момент публикации. От этой точки может отводится ветка для выпуска патч-релизов.

bX_YY

Имя ветки X.YY.ZZ. Ветка отводится от точки vX_YY и на ней производится разработка патч-релизов. Для получения текущего состояния пропатченной версии X.YY используется команда cvs co -r bX_YY project.

vX_YY_ZZ

Снимок проекта в момент публикации релиза. Для альфа и бета релизов такие метки соответствуют стволу, для патч-релизов эти метки получает проект, находящийся на ветке bX_YY.

vX_YY_ZZpreNN

Промежуточный снимок проекта. Используется при необходимости публикации состояния релиза до завершения работы над ним. Например, перед выходом релиза 1.1.1 или 1.1.80 могут быть точки, помеченные как v1_1_1pre1 или v1_1_80pre1.

Получение доступа к состояниям проекта:

cvs co test           # Текущее состояние работы над проектом.

cvs co -r bX_YY test  # Текущее состояние работы над патч-релизами.

cvs co -r vX_YY_ZZ    # Снимок релиза X.YY.ZZ

При публикации проекта в любой форме (export или checkout) всегда используется метка v..

2.2 Импорт

cvs import -d -m "Initial release 0.0.70" project author v0_0_70

2.3 Работа

cvs co project 

[changes]

cvs ci

2.4 Выпуск релиза

(релиз готов, сделаны все объединения веток и т.п. и commit после)

cvs co project

cvs tag v0_0_71

cvs ci

Публикация релиза:

cvs -q export -r v0_0_71 -kv -d project-0.0.71 project

Для облегчения идентификации релизов в каталоге проекта можно создать файл RELEASE, содержащий строку

$Name: v1-07 $

2.5 Создание ветки

cvs co -r v0_1 -d prj-0.1.1 project # получить базовый релиз

cd prj-0.0.1

cvs tag -b b0_1

cvs ci

2.6 Объединение веток

cvs co -r v0_1 -d prj-0.1.1 project # получить базовый релиз

cvs co -r b0_1_1 -j -d prj-0.1.1 project # объединить с веткой

2.7 Переименование файлов

Переименование сводится к копированию файла в репозитории и удалению старого файла. Идея описана в [2]. (скопировать файл в репозитории в новый удалить файл из cvs)

cvs update <nfile>        # получить новый файл из репозитория

cvs log <nfile>           # увидеть список тегов

cvs tag -d <tag1> <nfile> # удалить все теги

2.8 Удаление файлов

cvs rm -f <oldfile> 

cvs ci

Ссылки

1

http://sources.redhat.com/ml/autoconf/1998-10-x-1999-01/msg00352.html

2

http://www.loria.fr/ molli/cvs/cvs-FAQ/cvsfaq8.html#2C.4

3

http://davidfrico.com/051801.txt

4

http://faqchest.dynhost.com/prgm/cvs-l/cvs-99/cvs-9910/cvs-991013/cvs99103012_18117.html

5

http://mail.gnu.org/pipermail/autoconf/2000-January/003578.html

Версия

Id: vns_ru.lyx,v 1.4 2002/05/27 12:33:34