For sub releases add ability for dependencies and different release dates (for visualization on Gantt chart)

there needs to be a way to “decouple” the Release Dates (internal and external) of a sub-release from it’s roll-up release.

The scenario we are attempting to deliver is:

* We have 2 Products, “Product A“ and “Product B“. Both are fully functioning, independent products that are individually sellable. We then also combine these 2 products under a new product code as a “Solution C“ using both products and integration between them.
* When we associate the Release of either Product A or Product B with the Roll-up release (Solution C), the Release dates of Product A and Product B automatically update to match the release date of the roll-up release – there is no way to manage those release dates of the sub-releases other than updating the roll-up release. As these are still independent product releases, we would like to manage these as 3 independent release dates (Product A release date, Product B release date, and Solution C release date).

Can you please then address my points about capacity below and how we should solve them?

+1 to different sub release dates. One alternative would be creating a regular release for the feature in question and linking it's features to the sub release features

As capacity is only defined/tracked at the release level (from what I can gather), currently the only way you have for dealing with capacity planning for a phase is to use the master/sub release hierarchy.  It's entirely reasonable for a single release to have multiple phases that require their own capacity planning and progress reporting. Unfortunately doing it this way renders the burn down charts and progress updates useless because the release date is used to estimate the average burn down. So while master releases may have been intended to support the purposes you allude to, it's not necessarily how customers are currently using aha and that is to in order to  get around some other product limitations.  This is a fairly significant issue for us at the moment.

Master releases exist to support multiple sub releases with the same release date. If your releases don't have the same release date then a master release is not necessary.

Master releases are designed to help organizations which have a component architecture and all components are released as part of a single overall product. The master release helps manage changing release dates by automatically keeping all sub releases with the same release date.

Our workflow matches the above.  The assumption that sub-releases match the master release date does not match a multi-product release schedule.  This should be a setting.

Sub releases need to have the flexibility to have independent dates within the Master release.  In almost all projects these will be required to finish before the master release and the timeline should be associated with that timeframe.