We're operating in a CI/CD environment, and prefer to release "releases" (especially API's) as soon as they clear integration and performance testing. Forcing all of the sub-releases in a Master Release to inherit that release date is not meeting our needs. We'd prefer that the sub-releases retain their own release date (that's prior to the MR date.) In this way we can use MR's as would work for us: a body of work across multiple teams and products, which in many cases have dependencies on prior chunks completing before kicking off the next part.
Using MR's now forces us to input a lot of "component release" milestones and lengthy "regression" or cross-team testing phases. However, because the roadmap and timeline reporting views lack a way to display granular phases and milestones, all of that is lost in the consolidated dashboard views we want to publish. (Note: I'm posting a companion idea around this as well.)
|Release time frame|
Master releases are meant to be used as a way to create a visual roadmap that represents a combined delivery across multiple sub-releases. A master releases contains phases and milestones (representing the combined delivery steps) and sub-releases (which are releases at the product level).
With this in mind, master and sub-releases have the same release dates.