Можно использовать механизмы системы для того, чтобы настроить такой функционал. Опишите, как вы хотели бы это использовать (как теги?), я подскажу, как это можно сделать.
@@danila.sokolov , спасибо за ответ! По сути, мне нужно что-то близкое к тегам. А использование планируется такое: _ У меня есть несколько задач для внедрения функционала-1 и ещё несколько задач для внедрения функционала-2. Причём второй пакет задач во многом зависит от пакета-1. В джире для этого есть релизы: мы создаём 2 релиза, например, с версией 1.1 и 1.2. Задачи функционала-1 получат версию 1.1 и будут реализовываться в его ключе, а задачи функционала-2 уйдут в версию 1.2. _ Причём, если после реализации задач появится ошибка, требующая исправления - мы сделаем задачу, у которой будет 2 поля: 1. Актуальная версия, 2. Версия исправления. _ Соответственно, таким образом можно даже несколько лет спустя разобраться в переплетениях задач, если они нормально документируются. Мне тема очень интересна.
Вопрос понял, вот мой ответ. Мы внутри команды, на реальных проектах делаем так: - Внутри настроек проекта есть раздел "версии", где, по сути, можно сделать буквально то, о чём вы говорите. - Также, в теории, можно использовать словарь "категории задач" - внося туда версии, но мы его используем по назначению и делим на условный фронт / бэк. - Также, можно просто завести кастомное поле для задач и туда указать список допустимых значений, которыми и будут ваши версии. Я бы или вариант 1 или 3 использовал ;)
Умеет ли redmine создавать релизы/версии?
Можно использовать механизмы системы для того, чтобы настроить такой функционал. Опишите, как вы хотели бы это использовать (как теги?), я подскажу, как это можно сделать.
@@danila.sokolov , спасибо за ответ!
По сути, мне нужно что-то близкое к тегам. А использование планируется такое:
_ У меня есть несколько задач для внедрения функционала-1 и ещё несколько задач для внедрения функционала-2. Причём второй пакет задач во многом зависит от пакета-1. В джире для этого есть релизы: мы создаём 2 релиза, например, с версией 1.1 и 1.2.
Задачи функционала-1 получат версию 1.1 и будут реализовываться в его ключе, а задачи функционала-2 уйдут в версию 1.2.
_ Причём, если после реализации задач появится ошибка, требующая исправления - мы сделаем задачу, у которой будет 2 поля:
1. Актуальная версия,
2. Версия исправления.
_ Соответственно, таким образом можно даже несколько лет спустя разобраться в переплетениях задач, если они нормально документируются. Мне тема очень интересна.
Вопрос понял, вот мой ответ.
Мы внутри команды, на реальных проектах делаем так:
- Внутри настроек проекта есть раздел "версии", где, по сути, можно сделать буквально то, о чём вы говорите.
- Также, в теории, можно использовать словарь "категории задач" - внося туда версии, но мы его используем по назначению и делим на условный фронт / бэк.
- Также, можно просто завести кастомное поле для задач и туда указать список допустимых значений, которыми и будут ваши версии.
Я бы или вариант 1 или 3 использовал ;)
Сохранил в избранное. Спасибо большое за развёрнутые ответы! :
Первый вариант скорее всего имено то, что я и искал.
Всегда пожалуйста. Мне не сложно :)