Feature #8991

Nested versions for projects with sub-projects

Added by Andreas Bosch about 6 years ago. Updated about 1 year ago.

Status:NewStart date:2011-08-05
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Roadmap
Target version:-
Resolution:

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

Related to Redmine - Feature #374: Support for milestones/iterations as part of projects New
Related to Redmine - Feature #13387: Improving Redmine's version model (not just milestones) New
Related to Redmine - Feature #4585: Move a Version from one project to another New 2010-01-14
Related to Redmine - Feature #18126: Allow setting up version hierarchy New
Duplicated by Redmine - Feature #22790: Relation between main project version and sub-projects ve... Closed

History

#1 Updated by Andreas Bosch about 6 years ago

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

#2 Updated by Sylvain Guimond about 6 years ago

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

#3 Updated by Joel SCHAAL about 5 years ago

+1 me too !

#4 Updated by Asaf H about 5 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...

#5 Updated by Sebastian Hucke about 5 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). ;-)

#6 Updated by Thomas Robbs almost 5 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. ;)

#7 Updated by Daniel Felix almost 5 years ago

  • Category changed from Issues planning to Roadmap

Well I change this to Roadmap.

Maybe this could be benefit in combination with #374!

#8 Updated by Thomas Robbs almost 5 years ago

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

#9 Updated by Asaf H almost 5 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.

#10 Updated by Joel SCHAAL almost 5 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)

#11 Updated by Joshua DeClercq over 4 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.

#12 Updated by jean-philippe arnaud over 4 years ago

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

#13 Updated by Dipan Mehta almost 4 years ago

+1 for this.

#14 Updated by David Rahusen over 3 years ago

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

#15 Updated by Toshi MARUYAMA over 3 years ago

  • Related to Feature #4585: Move a Version from one project to another added

#16 Updated by Florian Gruber over 3 years ago

+1 for this!

#17 Updated by Anonymous about 3 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.

#18 Updated by Sebastian Paluch almost 3 years ago

+1!

#19 Updated by Justin MASSIOT over 2 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.

#20 Updated by budo kaiman about 2 years ago

+1
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.

#21 Updated by M. A. over 1 year 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
    • ...

#22 Updated by Sebastian Hucke over 1 year 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

#23 Updated by Dipan Mehta over 1 year ago

+1 very useful.

#24 Updated by Dipan Mehta over 1 year 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.

#25 Updated by Toshi MARUYAMA over 1 year ago

  • Duplicated by Feature #22790: Relation between main project version and sub-projects versions added

#26 Updated by Toshi MARUYAMA over 1 year ago

#27 Updated by Grégory Janiszewski over 1 year 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.

Nice things would be to have a simple way to answer to :
  • In which system version this software version is used ?
  • Which software is compatible with this hardware version ?

Really needed feature for us.

#28 Updated by shakib a over 1 year ago

+1

We have the same need too.

#29 Updated by Jonathan Tee about 1 year ago

+1

Also available in: Atom PDF