Redmine

I chose the category "Issues planning", but a category "Versions" would be more appropriate. Maybe such a category should be introduced?!

+1. I'm agree. I'm aloso looking for that functionality.

+1 me too !

+1. That would really help.
Managing projects with multiple components written and maintained by different developers is a complicated task. That would really help bringing things together.
BTW, I specifically registered to this site so I can request this feature...

+1. Would be very helpful! Sub-versions are IMO a perfect, consistent extension of sub-projects.

P.S.: I registered to answer this feature, too (like Asaf does). ;-)

+1 for this.

It is common for me to have a "Version" that makes sense to our Customer, but also a "Version" that makes sense internally to the project/sub-project.

• Project A - Version = 1.0
  • Sub-project A1 - Version = 2.0, 2.1, 2.2
  • Sub-project A2 - Version = 0.1, 0.2, 0.3

BTW, I just registered to comment on another issue, and I'm glad I did, so I could comment on this one. ;)

Thanks Daniel - I read #374 and I agree. The concepts/needs seem very similar.

I actually want to separate the concept of nested versions and sub projects.
For example - we have several components and several projects.
Each component has a subproject of its own, and some components are used in more than one project.

Then project A in version 1.7 is released with component X in version 4.1, and project B in version 3.0 is released with component X in version 5.0.
Component X can't be a subproject of both Project A and Project B, but I still want to have nested versions in this case.

Asaf, what you describe would be the perfect match to the needs of our Redmine.
And I guess the needs of other people too.

Now the question is what does it mean regarding the code ? Is it a heavy change ? Is anyone familiar with this part of the code ?
There are many features regarding multiple versions support in Redmine. But this feature does not seem like something that will come soon.

What is blocking those issues ? Are they incompatible ? It would be nice to have an answer from the guys behind Redmine (sorry if it has already been done and redone)

I'm pretty sure my proposal in #13387 encompasses what's requested here and other places with a major revamp of how versions are recorded. Let's unify all these different feature ideas behind a familiar and versatile model instead of getting too focused on particular use cases.

+1 Anybody knows if progress has been made on implementing such feature?

+1 for this.

+1! Would be very useful for correct handling of subproject dependencies.

+1 for this!

Lately I've been making use of a multi-select "Version" custom field inside the "Version" element, allowing any version to be linked to any other versions by checking boxes (pre-2.5.x it would be a select list). But while it makes it easier to access one version from the roadmap of another (they simply show as version links), it does nothing for the issues linked to the different projects or versions.

At the same time, giving versions a parent/child hierarchy of their own might solve many issues, but I get the feeling it would also include a lot of complexity with fetching, filtering and updating issue data. Keeping in mind you will then need to not only maintain a "tree of projects" and their versions, but do this as a "tree of projects" linked to a "tree of versions"..

Not to throw a spanner is the works here, but just thinking out loud: would it not make more sense to use milestones on the parent project, which can then be shared with any child projects? I can see a structure where a number of versions from a tree of projects are assigned to a single milestone on a parent, while still allowing each project to progress and be versioned as an individual project. I for one would hate to lose the clear simplicity of the current "Roadmap" view for a single project.

+1!

+1 also for me!
I think that is really a must have.

I used Redmine as a bug-tracker for embedded software projects (hardware and software combined). We defined versions for the whole product, and independent versions for the software and the hardware. But we could not assign a hardware version to a product version for example.
Having this possibility in Redmine would welcome the multi-skilled projects wide open, as well as very big software development projects. But today it is a lack of functionnality and I am evaluating Redmine alternatives for my future projects.

• V1.0.0
  • sprint 1
  • sprint 2
  • etc...

as opposed to having to setup sub-projects or just have lingering version links without any actual meaning.

I am also looking for this functionality.
Are there any news?
We have releases of projects A, B, C with all their sub-projects at the same time.

• Software 1.0 (Project Milestone)
  • Software A 1.5
  • Software B 3.1
  • ...
• Software 2.0 (Project Milestone)
  • Software A 2.0
  • Software B 3.2
  • ...

M. A. wrote:

I am also looking for this functionality.
Are there any news?
We have releases of projects A, B, C with all their sub-projects at the same time.

• Software 1.0 (Project Milestone)
  • Software A 1.5
  • Software B 3.1
  • ...
• Software 2.0 (Project Milestone)
  • Software A 2.0
  • Software B 3.2
  • ...

We use a plugin to achieve this functionality: https://github.com/Coren/redmine_advanced_roadmap_v2

+1 very useful.

Sebastian Hucke wrote:

M. A. wrote:

I am also looking for this functionality.
Are there any news?
We have releases of projects A, B, C with all their sub-projects at the same time.

• Software 1.0 (Project Milestone)
  • Software A 1.5
  • Software B 3.1
  • ...
• Software 2.0 (Project Milestone)
  • Software A 2.0
  • Software B 3.2
  • ...

We use a plugin to achieve this functionality: https://github.com/Coren/redmine_advanced_roadmap_v2

This plug-in is very good and useful. However, it introduces entries 'milestone' which is a different entities. Here we are talking about versions related to version - a functionality required is rather different and should be in core.

+1

We have the same need.
Just to add a new point of view for this feature : We have "System" point of view, made of subsystems.

For example :
System made of hardware + software + wiring + housing +...
So each subsystem have its own roadmap today and could be totally different jobs/skills (There is not only software development! Even if I am soft dev.)
But at system level, the roadmap of the system is made of subproject version, this ensure compatibility between each subprojects.

• In which system version this software version is used ?
• Which software is compatible with this hardware version ?

Really needed feature for us.

+1

We have the same need too.

+1