Как Поле версии должно использоваться в Trac?
Я использую Trac для отслеживания ошибок и будущих изменений в моих проектах программного обеспечения. Билеты в Trac имеют поле "Version", и я пытаюсь выяснить лучший способ использовать это поле.
Скажите, что я нахожу серию ошибок в версии 1.0 моего программного обеспечения. Я создаю тикеты в дорожке для каждого и присваиваю их версии 1.0. Теперь скажите, что я исправляю некоторые ошибки и добавляю некоторые новые опции и версию выпуска 1.1. Но некоторые из старых 1,0 ошибок находятся все еще в 1,1. Я должен изменить их соответствующие билеты на версию 1.1, потому что они также теперь существуют в 1,1? Или я должен оставить их набором версии 1.0 как способ отследить, в какой версии ошибка была найдена, и просто предположите, что какие-либо открытые билеты в более старых версиях все еще существуют в более новых версиях?
3 ответа
Я бы обычно использовал поле версии, чтобы указать версию, в которой была обнаружена ошибка. Я бы используйте веху, чтобы указать, в какой версии будет исправлена заявка. Если заявка открыта, она не была исправлена.
Один из подходов - тегировать сборки с использованием подходящего номера версии. Затем довольно легко обновить поле версии с помощью TracLink по мере развития заявки.
Приложение: Несколько примеров использования TracLink в поле версии можно найти в билетах , связанных с самим Trac . Многие оставляют это поле пустым. Некоторые, включая билет № 8146 , реализуют Trac Ticket Queries . Другие указывают на связанные вехи и т. Д. Использование столь же разнообразно, как и сами билеты.
Всегда есть возможность обновить некоторые поля непосредственно в sqlite или mysql. Если вы знакомы с python, вы можете разработать небольшой скрипт на python, который выполнит эту работу. предполагая, что вы выпускаете один или два раза в год ...