Project

General

Profile

Actions

Feature #8991

open

Nested versions for projects with sub-projects

Added by Andreas Bosch over 12 years ago. Updated over 7 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Roadmap
Target version:
-
Start date:
2011-08-05
Due date:
% Done:

0%

Estimated time:
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 projectsNew

Actions
Related to Redmine - Feature #13387: Improving Redmine's version model (not just milestones)New

Actions
Related to Redmine - Feature #4585: Move a Version from one project to anotherNew2010-01-14

Actions
Related to Redmine - Feature #18126: Allow setting up version hierarchyNew

Actions
Has duplicate Redmine - Feature #22790: Relation between main project version and sub-projects versionsClosed

Actions
Actions #1

Updated by Andreas Bosch over 12 years ago

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

Actions #2

Updated by Sylvain Guimond over 12 years ago

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

Actions #3

Updated by Joel SCHAAL over 11 years ago

+1 me too !

Actions #4

Updated by Asaf H over 11 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...

Actions #5

Updated by Sebastian Hucke over 11 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). ;-)

Actions #6

Updated by Thomas Robbs over 11 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. ;)

Actions #7

Updated by Daniel Felix over 11 years ago

  • Category changed from Issues planning to Roadmap

Well I change this to Roadmap.

Maybe this could be benefit in combination with #374!

Actions #8

Updated by Thomas Robbs over 11 years ago

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

Actions #9

Updated by Asaf H over 11 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.

Actions #10

Updated by Joel SCHAAL over 11 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)

Actions #11

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

Actions #12

Updated by jean-philippe arnaud almost 11 years ago

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

Actions #13

Updated by Dipan Mehta over 10 years ago

+1 for this.

Actions #14

Updated by David Rahusen almost 10 years ago

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

Actions #15

Updated by Toshi MARUYAMA almost 10 years ago

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

Updated by Florian Gruber over 9 years ago

+1 for this!

Actions #17

Updated by Anonymous over 9 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.

Actions #18

Updated by Sebastian Paluch over 9 years ago

+1!

Actions #19

Updated by Justin MASSIOT about 9 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.

Actions #20

Updated by budo kaiman over 8 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.

Actions #21

Updated by M. A. almost 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
    • ...
Actions #22

Updated by Sebastian Hucke almost 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

Actions #23

Updated by Dipan Mehta almost 8 years ago

+1 very useful.

Actions #24

Updated by Dipan Mehta almost 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.

Actions #25

Updated by Toshi MARUYAMA almost 8 years ago

  • Has duplicate Feature #22790: Relation between main project version and sub-projects versions added
Actions #26

Updated by Toshi MARUYAMA over 7 years ago

Actions #27

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

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.

Actions #28

Updated by iransamin.ir sabasa over 7 years ago

+1

We have the same need too.

Actions #29

Updated by Jonathan Tee over 7 years ago

+1

Actions

Also available in: Atom PDF