Номера версий openbravoposru
Gennady Kovalev
Основная ветка - trunk - ветка для нестабильных версий для
разработчиков. Туда коммитится код, который можно скомпилировать и
приложение при этом не падает. Сюда можно коммитить стабы (заглушки), не
готовый функционал. Эта ветка для разработчиков "на каждый день". При
этом мы понимаем, что этот код не стабильный, на реальные машины мы этот
код не ставим.
Далее когда trunk набирает критическое количество изменений, то мы
делаем новый branch. Обзываем его, например
openbravoposru-1.0.0-freeze
Далее отдельно уже работаем внутри этого branch, исправляем только
ошибки, стабилизируем его и все. Как только видим, что код в этом branch
стабильный, переименовываем branch в
openbravoposru-1.0.0
Таким образом у нас будет нестабильная разработка отдельно, а стабильный
код - отдельно.
Версии предлагаю нумеровать в два числа. Первое увеличиваются когда
сделаны очень значительные и существенные изменения. Примерно 50% кода
полностью переписано. Второе число увеличивается, когда сделаны
существенные изменения. А третье - когда сделаны мелкие изменения:
незначительный функционал, исправлены ошибки и т.д.
Таким образом картина бранчей через много времени у нас может быть такая:
openbravoposru-1.0.0
openbravoposru-1.0.1
openbravoposru-1.0.2
openbravoposru-1.1.0
openbravoposru-1.1.1
openbravoposru-1.1.2
openbravoposru-1.1.3
openbravoposru-1.1.4-freeze
и т.д.
С текущим кодом предлагаю так. Я еще неделю тестирую драйвер для
Штрих-ФР. Затем объявляю его работоспособным, и мы делаем merge бранча
bigur в бранч trunk. При этом branch bigur уничтожаем.
Уже сейчас объявляем, что следующая версия будет называться
openbravoposru-1.0.0. Залезаем в Issues и создаем там такие milestones:
openbravoposru-1.0.0
openbravoposru-1.1.0
openbravoposru-2.0.0
Проходимся по всем Issues и разбрасываем их по версиям: 1.0.0 - то, что
мы хотим увидеть в ближайшем выпуске, 1.1.0 - то, что мы не включим в
ближайший выпуск, но имеем ввиду заняться этим очень скоро. И 2.0.0 -
то, что надо делать в принципе, но займемся этим в далеком будущем.
Остальные Issue - закрываем с различными формулировками.
Потом смотрим что же у нас получается на релиз 1.0.0, выполняем работы
по этим Issues, закрываем их, делаем openbravoposru-1.0.0-freeze,
тестируем, делаем openbravoposru-1.0.0.
Предложения? Критика? Комментарии?
--
Геннадий Ковалёв,
Генеральный директор компании "Бигур",
http://www.bigur.ru/
Andrej Svininykh
> Предлагаю для организации разработки ввести такую структуру кода.
> Версии предлагаю нумеровать в два числа. Первое увеличиваются когда
> сделаны очень значительные и существенные изменения. Примерно 50% кода
> полностью переписано. Второе число увеличивается, когда сделаны
> существенные изменения. А третье - когда сделаны мелкие изменения:
> незначительный функционал, исправлены ошибки и т.д.
Согласен, но до версии 1.0.0, чтобы выполнить условие в 50%, ещё
работать и работать. Та псевдосистема нумерации, что сейчас у меня
существует была построена на сроках, так как работал один, то делал в
марте-апреле паузу чтобы собраться с мыслями и составить план на новый
год. Если её переводить в предложенную систему счисления, то
получится:
- версия 0.1.0, будет соответствовать итогам Stage1st, в неё вошла
полная локализация интерфейса на русский язык;
- версия 0.2.0, будет соответствовать итогам Stage2nd, она была
основана на коде Openbravo POS 2.20 и в неё вошли первые мои
разработки по поддержки оборудования и изменению интерфейса системы;
- версия 0.3.0, будет соответствовать итогам Stage3rd, это текущий
этап разработки, код в нём основан на Openbravo POS 2.30.2, одной из
основных задач этого этапа является поддержка всех типов оборудования
используемого с POS системами.
Основная задача Stage3rd будет выполнены когда Геннадий закончит
разработку поддержки для фискального регистратора, а я доделаю
поддержку весов с печатью этикеток. По этому:
1. Чтобы сохранить наследственность перейти к системе нумераций версий
когда будут закончены эти две задачи (по своей части работы, если
ничего не помещает должен к майским уложится).
2. По итогам этой работы зафиксировать пакет с исходным кодом за
номером 0.3.0. А дальше вести работу над ошибками и дополнение
функционала пока не накопится до следующей версии.
> С текущим кодом предлагаю так. Я еще неделю тестирую драйвер для
> Штрих-ФР. Затем объявляю его работоспособным, и мы делаем merge бранча
> bigur в бранч trunk. При этом branch bigur уничтожаем.
Да, а я чтобы никого не путать уничтожаю /branches/Stage3rd
> Уже сейчас объявляем, что следующая версия будет называться
> openbravoposru-1.0.0. Залезаем в Issues и создаем там такие milestones:
>
> openbravoposru-1.0.0
> openbravoposru-1.1.0
> openbravoposru-2.0.0
Движок GoogleCode такой, что удобней создать метки Milestone-1.0.0 и
т.д. И следующую версию я бы нумеровал 0.4.0, но если накопится на
1.0.0, то будет просто замечательно.
До этого письма я уже прошёлся по Issues и что было на каких этапах
обозначил, можно всё это по выше описанной схеме переобозначить
номерами.
> Проходимся по всем Issues и разбрасываем их по версиям: 1.0.0 - то, что
> мы хотим увидеть в ближайшем выпуске, 1.1.0 - то, что мы не включим в
> ближайший выпуск, но имеем ввиду заняться этим очень скоро. И 2.0.0 -
> то, что надо делать в принципе, но займемся этим в далеком будущем.
>
> Остальные Issue - закрываем с различными формулировками.
Это тоже сделал, до этого письма. Всё что сейчас стоит с открытыми
статусами нужно будет раскидать по плану выпуска версий. Только пока
рано начинать с 1.0.0, можно обойтись второй и третьей цифрой :)
> Потом смотрим что же у нас получается на релиз 1.0.0, выполняем работы
> по этим Issues, закрываем их, делаем openbravoposru-1.0.0-freeze,
> тестируем, делаем openbravoposru-1.0.0.
"openbravoposru" - вот с этой частью названия есть две проблемы,
которые пока не сильно важны, но над ними надо подумать уже сейчас:
1. Название проекта основано на чужой торговой марке, пока не
выпускаем готовых сборок, я думаю к нам претензий не будет.
2. Если слитно и быстро прочесть название, то оно на русском языке
звучит не благозвучно, мне уже рекомендовали название проекта с
приставкой ru употреблять пореже.
> Предложения? Критика? Комментарии?
Что описал выше мои предложения и комментарии. Если есть что дополнить
или возразить будет интересно выслушать.
Gennady Kovalev
> On 14 апр, 01:30, Gennady Kovalev<g...@bigur.ru> wrote:
>> Предлагаю для организации разработки ввести такую структуру кода.
> Предложенная структура работы с кодом меня полностью устраивает.
> - версия 0.3.0, будет соответствовать итогам Stage3rd, это текущий
> этап разработки, код в нём основан на Openbravo POS 2.30.2, одной из
> основных задач этого этапа является поддержка всех типов оборудования
> используемого с POS системами.
> Основная задача Stage3rd будет выполнены когда Геннадий закончит
> разработку поддержки для фискального регистратора, а я доделаю
> поддержку весов с печатью этикеток. По этому:
>
> 1. Чтобы сохранить наследственность перейти к системе нумераций версий
> когда будут закончены эти две задачи (по своей части работы, если
> ничего не помещает должен к майским уложится).
> 2. По итогам этой работы зафиксировать пакет с исходным кодом за
> номером 0.3.0. А дальше вести работу над ошибками и дополнение
> функционала пока не накопится до следующей версии.
Ну значит я доделываю драйвер для Штриха, сливаем bigur в trunk,
работаем уже над trunk, и когда созреем - то делаем стабильную версию
0.3.0. И делаем milestone в трекере.
Название проекта ты предлагай. Твое-же :)
Andrej Svininykh
получается для 0.3.0 http://code.google.com/p/openbravoposru/issues/list?can=1&q=milestone=0.3.0
Это только то что уже сделано, т.е. находится в статусе Fixed или
Verified. Начал расставлять, то что из не сделанного планируем
закончить к версии 0.3.0 и у меня возникло предложение.
Предлагаю следующие принципы в расстановке приоритетов выполнения:
Priority-Critical, маркируются проблемы возникшие в коде предложенном
к стабилизации или выявленные в ходе использования. Их решение ведёт к
выпуску версий с кодами в последнем разряде.
Priority-High, маркируются задачи которые планируется реализовать в
ближайшей версии. Их решение является приоритетным для участников
проекта и ведёт к выпуску версий с номером во втором разряде.
Priority-Medium, маркируются задачи которые могут быть реализованы в
ближайшей версии, но если этого не произойдёт, то могут быть отложены
до выхода следующей. Также с этим статусом могут маркироваться работы
которые уже выполнены и опубликованы в код, но требуется их проверка
со стороны участников сообщества.
Priority-Low, маркируются задачи которые принимаются к рассмотрению и
могут быть реализованы в следующих версиях, но их выполнение является
не приоритетным для текущих участников проекта. Если найдётся тот кто
решит взяться за их решение, приоритет этих задач может быть повышен.
Сегодня попробую по этим принципам раскидать, то что осталось не
решённым. Посмотри может ты как-то по своему распределишь.
Название пусть пока будет такое, переребрендиться со скандалом, это
всегда отличный пиар ход :)
Gennady Kovalev
> Я тут вроде раскидал лежащие в Issues репорты по версия. Вот что
> получается для 0.3.0 http://code.google.com/p/openbravoposru/issues/list?can=1&q=milestone=0.3.0
> Это только то что уже сделано, т.е. находится в статусе Fixed или
> Verified. Начал расставлять, то что из не сделанного планируем
> закончить к версии 0.3.0 и у меня возникло предложение.
>
> Предлагаю следующие принципы в расстановке приоритетов выполнения:
Ну, как мне кажется, приоритет - это степень важности, серьезности
проблемы. Самый высокий - это, например, программа падает вообще. Или
искажаются данные. А самый низкий - например концы строк.
А что касается версионности, и когда issue может быть решен, то это надо
просто сделать на будущее milestone: 0.4.0 и 1.0.0. И просто раскидать
тикеты, которые "не охота" делать - в 1.0.0. Типа "на потом".
И это уже некий элемент планирования.