Feature #8991
open
Nested versions for projects with sub-projects
0%
Description
It would be nice if there could also be nested versions if a project has sub-projects. I would have called it "sub-versions" because it better fits to "sub-projects", but this would only confuse everyone.
For example, we often have the following structure:
- Project A
- Project A_1
- Project A_2
- Project A_3
- Project A_4
- Project B
- Project B_1
- Project B_2
- Project C
- Project C_1
- Project C_2
- Project C_3
Most of the time, we have releases of projects A, B, and C with all their sub-projects at the same time. Therefore, we also have (release) versions for projects A, B, and C. But the sub-projects A_1, A_2... all have their own software versions, and they are different from sub-project to sub-project, i.e. A_1 has a different version than A_2. But they are released with the same project A release.
For example:
- Project A - v2011-08
- Project A_1 - v1.3.0.1
- Project A_2 - v2.4.6.0
- Project A_3 - v1.6.3.4
- Project A_4 - v3.0.0.0
Now, I can define a version for project A ("v2011-08"), share this version with its sub-projects, and assign all issues in A_1, A_2, A_3, and A_4 to this version. But then I lose the sub-projects' versions (v1.3.0.1, v2.4.6.0...).
I would prefer if it was possible to make a version a "sub-version" of a parent project's version, like this:
- v2011-08 (Project A)
- v1.3.0.1 (Project A_1)
- v2.4.6.0 (Project A_2)
- v1.6.3.4 (Project A_3)
- v3.0.0.0 (Project A_4)
Now, if I assign an issue to v1.3.0.1, it will automatically appear in v2011-08 as well. Probably, it should be configurable if those sub-versions are displayed in the parent version.
Basically, this seems to be the same as what is done with projects and sub-projects.
Related issues
Updated by Andreas Bosch over 13 years ago
I chose the category "Issues planning", but a category "Versions" would be more appropriate. Maybe such a category should be introduced?!
Updated by Sylvain Guimond about 13 years ago
+1. I'm agree. I'm aloso looking for that functionality.
Updated by Asaf H about 12 years ago
+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...
Updated by Sebastian Hucke about 12 years ago
+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). ;-)
Updated by Thomas Robbs about 12 years ago
+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.
E.g.- 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. ;)
Updated by Daniel Felix about 12 years ago
- Category changed from Issues planning to Roadmap
Well I change this to Roadmap.
Maybe this could be benefit in combination with #374!
Updated by Thomas Robbs about 12 years ago
Thanks Daniel - I read #374 and I agree. The concepts/needs seem very similar.
Updated by Asaf H about 12 years ago
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.
Updated by Joel SCHAAL about 12 years ago
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)
Updated by Anonymous over 11 years ago
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.
Updated by jean-philippe arnaud over 11 years ago
+1 Anybody knows if progress has been made on implementing such feature?
Updated by David Rahusen over 10 years ago
+1! Would be very useful for correct handling of subproject dependencies.
Updated by Toshi MARUYAMA over 10 years ago
- Related to Feature #4585: Move a Version from one project to another added
Updated by
Updated by Anonymous about 10 years ago
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.
Updated by
Updated by Justin MASSIOT almost 10 years ago
+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.
Updated by budo kaiman about 9 years ago
This would fix my issues with the current version system, which does not work well for agile management. It would be much easier (and make a lot more sense) to have:
- 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.
Updated by M. A. over 8 years ago
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
- ...
Updated by Sebastian Hucke over 8 years ago
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
Updated by Dipan Mehta over 8 years ago
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.
Updated by Toshi MARUYAMA over 8 years ago
- Has duplicate Feature #22790: Relation between main project version and sub-projects versions added
Updated by Toshi MARUYAMA over 8 years ago
- Related to Feature #18126: Allow setting up version hierarchy added
Updated by Grégory Janiszewski over 8 years ago
+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.
Updated by 
Updated by