Vote #70474
未完了Nested versions for projects with sub-projects
0%
説明
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.
journals
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.
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. ;)
--------------------------------------------------------------------------------
Well I change this to Roadmap.
Maybe this could be benefit in combination with #374!
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
+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.
--------------------------------------------------------------------------------
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.
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.
--------------------------------------------------------------------------------
+1
We have the same need too.
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
related_issues
relates,New,374,Support for milestones/iterations as part of projects
relates,New,13387,Improving Redmine's version model (not just milestones)
relates,New,4585,Move a Version from one project to another
relates,New,18126,Allow setting up version hierarchy
duplicates,Closed,22790,Relation between main project version and sub-projects versions