Group Milestones and Issues > 1 Level (also for Subgroups)
Description
In our on-premise-gitlab after updating to 10.8.1, I just got the message that Milestones should be promoted to group milestones because project milestones will be removed in the future. The reason why group milestones should be used is according to the message, that it's more future-proof as the project might grow later.
However, Group milestones are pretty useless for us at the moment as they aren't inherited more than one level. The same goes for group issues, which is the reason that we have a seperate project to track the issues independent from our development.
Example:
RootGroup with Milestone 1
- Project 1 (Milestone 1 available)
-- Plugins (Subgroup) (Milestone N/A!)
--- Plugin 1 (Milestone N/A!)
-- Libraries (Subgroup) (Milestone N/A!)
--- Lib 1 (Milestone N/A!)
Proposal
Milestones should be inherited to all subgroups and subprojects to allow unified version management. Also group issues should be available for all subgroups and subgroup-projects, as they all depend on the same parent group.
Maybe there could be an option to break inheritance for the subgroup, but my personal opinion on this is, that if there's independent version and issue management needed, the subgroups wouldn't be a subgroup but an Independent group.
New Functionality Example:
RootGroup (Issue 1, Milestone 1)
- Subgroup 1 (Issue 2, Milestone A)
-- Project 1 (Issue 1,2, Milestone 1,A
Links / references
I created the project https://gitlab.com/GroupMilestones which shows, that Milestones aren't inherited to subgroups, but are inherited to direct children projects.