Версионность

Здравствуйте! Сейчас занимаюсь таким вопросом, как разработка документа "Версионность программного продукта"! Кто-нибудь этим занимался когда-нибудь? Какие пункты включали в этот документ, то есть вот вышла новая версия программного продукта, Вам необходимо это задокументировать! Что вы будете описывать, коме функций? Как происходит нумерация я уже нашел! Может кто поделится?

Честно говоря я не слышала про какие либо стандарты оформления такого документа, в нашей компании версионность поддерживается автоматически, есть небольшой документ. Но он только для служебного пользования программистами :) У нас схема присвоения нумерации такая:
а.номер версии состоит из двух частей, разделенных символом, обычно ".";
б.цифры до точки обозначают номер основной версии (major version);
в.1—2 цифры после точки обозначают номер вспомогательной версии (minor version).
Изменение номера основной версии происходит при внесении в программу серьезных изменений, например, при смене интерфейса, включении новых функций, значительно повышающих возможности продукта. Если были внесены небольшие изменения, то меняется первая цифра после точки, если сделаны незначительные изменения, то меняется вторая цифра после точки, иногда используют еще номера релиза или билда.

Если исходить из позиции что вы будете "присваивать номера" по схожему принципу, то в таком документе должны быть описаны: регламент, правила и особые ситуации процедуры присваивания номера версии. По шаблону. Этот документ должен быть рассмотрен, и утвержден вышестоящим начальством. Как то так.

Честно говоря я не слышала про какие либо стандарты оформления такого документа, в нашей компании версионность поддерживается автоматически, есть небольшой документ. Но он только для служебного пользования программистами :) У нас схема присвоения нумерации такая:
а.номер версии состоит из двух частей, разделенных символом, обычно ".";
б.цифры до точки обозначают номер основной версии (major version);
в.1—2 цифры после точки обозначают номер вспомогательной версии (minor version).
Изменение номера основной версии происходит при внесении в программу серьезных изменений, например, при смене интерфейса, включении новых функций, значительно повышающих возможности продукта. Если были внесены небольшие изменения, то меняется первая цифра после точки, если сделаны незначительные изменения, то меняется вторая цифра после точки, иногда используют еще номера релиза или билда.

Если исходить из позиции что вы будете "присваивать номера" по схожему принципу, то в таком документе должны быть описаны: регламент, правила и особые ситуации процедуры присваивания номера версии. По шаблону. Этот документ должен быть рассмотрен, и утвержден вышестоящим начальством. Как то так.

Ну на счет присвоения нумерации мы уже разобрались и договорились!
Мне вот интересно само содержание документа!
НапрерЮ вышла новая версия, в ней описаны новые функции, что кроме функций(какие еще пункты) можно включить в данный документ! може есть шаблончик?

НапрерЮ вышла новая версия, в ней описаны новые функции, что кроме функций(какие еще пункты) можно включить в данный документ! може есть шаблончик?

Шаблончика в файле нету, есть древний набросок сего чуда(на бумаге), выглядит так:
Шапка документа(название, кем когда составлен, кем когда утвержден).
Содержание:
1.Регламент присваивания продукту версии.
2.Правила присваивания продукту версий.
3.Особые ситуации.
4.Терминология
Пронумерованный и прошитый как в делопроизводстве.
Регламент описывает кто и каким образом в технических подробностях присваивает номер продукту(например в svn'ne ставим мажорную такую то версию). А в правилах описано по каким критериям это делать (т.е. например изменена функция, название по, что то еще). Т.е. в нем нет ведения каждой версии. Там просто порядок как и что и когда и кому делать.
В п.3 просто исключения, когда номер версии не меняется. В п.4 просто расшифровка используемых сокращений.
А для контроля версий мы используем Jira, в ней же есть набросок этого документика.

Ну на счет присвоения нумерации мы уже разобрались и договорились!
Мне вот интересно само содержание документа!
НапрерЮ вышла новая версия, в ней описаны новые функции, что кроме функций(какие еще пункты) можно включить в данный документ! може есть шаблончик?

уй....у меня объем документирования на новую версию ООООчень большой.

Выжимка (абстрактно - прям сейчас сочиняю) примерно такая:
- новые функциональности;
- изменения проекта/архитектуры.
- на какой версии компилятора/окружения разработано;
- на какой платформе/каком железе может работать;
- какие баги нашли, но в этой версии решили не исправлять;
и т.д. и т.п.

В целом - сильно индивидуально.
ИМХО.
Для игр - одно, а для ПО томографа - другое.

Все в целом - один из аспектов Процесса Управления Конфигурации.

Начните с того, что определите, КТО будет пользоваться документом. И ЗАЧЕМ такой документ нужен.

Есть такой вариант:
одна большая система состящая из разных модулей
Есть версии на модули,
есть версия сборки системы.
Каждое изменение вресии модуля - ++ к версии сборки системы.

На каждый модуль есть док. Номер версии модуля привязан к номеру дока.
док состоит из общих требований, ограничений реализаций и юз кейсов. Менятеся редко. Называется ТЗ.
док состоит из описания классов функций и описания архитектуры - програмисты такое писать терпеть не могут и пишут под пистолетом. Называется описание реализации. Менятся постоянно. Как правило присутствует только на первую и последнюю замороженную версию. Поэтому на многие модули есть только ТЗ.
Если написаны какие-то доки по тестированию - они аттачатся к версии реализации модуля. В том числе и баги.
Есть вообще не рабочие промежуточные версии которые наследуют требования от более ранних версий и уникальны набором багов.

На версии сборки писать доки пока никого заставить не удалось. Так что пока на версии сборки появляются только списки багов.

А номер формируется так 0.1.0 - первый раз начали работать
0.1.1 - исправили баги
0.2.0 - изменили ТЗ
1.0.0 - установили на рабочий сервер

вот примерно так...

На мой взгляд, речь должна идти о двух документах:
1. "Версионность программного продукта" - правила выпуска новых версий. Здесь нужно определиться с терминологией (что такое версия ПП, minor, major и пр.) и описать некие общие принципы, касающиеся выхода версий - версии только с исправлением ошибок, версии с новыми функциональными функциональными возможностями и т.п. Сказать, как это привязано к нумерации. Версии, вероятно, должны сопровождаться определенной документацией. Возможно комплект этой документации будет зависеть от типа версии (какая цифра в наборе меняется). Тогда это тоже нужно описать в документе.
2. Документ, описывающий содержимое изменений в очередной версии ПП (стандартный Release description, можно посмотреть в википедии). Этим документом должна сопровождаться версия ПП; соответственно документ должен выходить вместе с версией. Шаблон этого документа можно включить в документ "Версионность программного продукта".

Сейчас занимаюсь таким вопросом, как разработка документа "Версионность программного продукта"!
вот вышла новая версия программного продукта, Вам необходимо это задокументировать!

Документ "Версионность продукта" по идее должен описывать правила создания версий всей системы и включённых в неё компонент.
А описание изменений и улучшений, реализованных в новой версии - это документ с иным названием, типа history.txt ;)