Allow sub-releases to have independent release dates from a Rollup Release date

I still voted for this. My argument:

I understand the intention behind having the internal and external release dates synced within a roll-up release, but I wanted to provide some additional feedback based on our use case.

When we relate our releases to the roll-up release, both the internal and external release dates are automatically synced. While it makes sense to sync external release dates for Go-To-Market and post-deployment activities that are coordinated across products, the internal release date reflects our actual deployment timeline. For example, in this case, the deployment happened on Sep 9 but the external release will be on Sep 25, so I need the internal release date to accurately reflect that, even though the external release aligns with the roll-up release for communication and coordination purposes.

I'd like using the rollup release to group all the sub releases for reaching a summary of all the GTM activities we did for example in the last quarter, while the sub releases GTM activties are done in a continuous deployment mode. The limitation today of sub-releases dates are of the rollup parent release is not allow me to control the exact dates of the sub releases. So although I like the grouping, I cannot really use the functionality and I missed this part.

Hi all,

and now it is my time to add one more vote... And I really do agree with the others that wrote before me.

In our company, we have now come to the point that we also will need to use roll-up releases. In our use case, we will have new releases that will contribute to the roll-up release. But also already shipped releases from another division, the roll-up release owner wants to link them into the roll-up release. And in this case, in an already completed and already shipped release... the release date jumps to the release date to the roll-up release, and the old one is gone. And when I de-attach the release again, it stays on the roll-up release date. So the original date that was set seems to be gone.

My thoughts on this:
We already have internal and external release date fields.
Why can't we have a "roll-up release date" also?

Then you can have your sub-release date on that level, but you can also see the roll-up release date.

Let it turn into red text or let's get a warning, if the sub-release date is after the roll-up release date.
Even for those that think that a view on a Gantt chart is not enough.

I can just agree, this proposed (needed and useful) improvement was posted in the year 2016.

And now I must also solve this in some way with an extra "sub-release date" milestone...
And explain to the sub-releases owners why their dates will jump around.

Best regards from Sweden! =)

Hi Aha! Team

I agree this feature is a must have for the successful management of releases. The concept of Parent and Child Releases is useful in the system however determining the Sub-release End Date based on the Parent Release date does not make sense, maybe this could be an option at the Sub-release level but there needs to be a way to release dates at the child level independent of the parent.

The issue is with the End Date automatically assigned to a Child Release when selecting to base the dates on the 'Phase and Features' of the Child Release.

When applying this setting I would expect the Child Release to base the Start and End Dates of the Release on the phases and features within the Chile Release. However this is not the result I am getting currently.

Start Date: Currently the Aha! system is selecting the Start Date based on the Child Release phases and features - this is as expected.

End Date: The issue is with the End Date that seems to be pulling the data from the Roll-up Release End Date, this does not make sense as the child release will be complete before the e2e parent release. My expected result is that the end date of the child release is determined by the sub features and phases and is independent of the Parent Release End Date.

Thanks

Mark

Hi team Aha!

Is there any chance this could be looked at with fresh eyes (given the admin response was written 7 years ago in 2016)? As with other responses noted here, the master release is a great concept and would help us immensely in differentiating between a market release (the master / finished feature or product) and version releases (the subs) as is the case with CI/CD.

Like others, we can't use master releases as we need subs to have an different date. And in reality, they do have different dates. Aha's understanding works for some practices, and when feature toggles and brilliant tools like LaunchDarkly weren't a thing, but I feel (with respect) you've lost touch with how some (although I suspect a lot) of your customers are functioning in 2023.

Use case:
In our payroll product we are adding the ability to track employee leave. Many of the components exist already as part of the core offering (employees, pay items etc) so the new feature components can be built, tested and released with a feature toggle independently (in multiple releases) until the completed feature is ready to launch (also noting as we all know, the release date isn't the launch date).

As the master release has multiple releases from multiple products (workspaces) with multiple epics and stories, there are MANY different release dates, therefore forcing the same release date doesn't make any sense to my brain.

We have also worked with the awesome Aha support team on this twice, and whilst they have suggested several alternatives, the simplest fix for me is to allow rolled up releases to have independent release dates.

Cheers, Jason.

i don't understand what world a master release is comprised of sub releases that coincidentally have the same date. There is always one long pole or short pole in a master release time line making the date the latest end date of any sub release. I agree with the rest, this defeats any use of master releases i can envision.

We also have this challenge when trying to use Mater Releases, and in addition to the comments already posted, we have found that using Master Releases causes our Feature Boards to dramatically shift as the sub-releases are now all ordered sequentially by the Master Release date, instead of the sub-release date. Please reconsider implementing the option to control the release date from the Master Release OR the original sub-release date. Without this, we are not able to use any of the Master Release capabilities within Aha.

The use case Carsten spells out is exactly what we do. We have 1 main product release and follow it up with periodic feature releases until the next major product release. We would like the Master Release to be a definition of a product "generation" if you will. In each Generation, you can have various product releases of a variety of products in our main product line, each with different dates/milestones and features, etc.

I would think that since Master Releases have very little metadata that they actually own, that having a Master Release relinquish control of dates for the Sub-Releases should be fairly easy.

My proposal is that dates for Master Releases be optional and they are essentially a container used to organize Sub-Releases. This would be immensely helpful for our planning and road map visualizations.

I am not sure if that would meet the other use cases on this thread, but for us it would be perfect and a small deviation from your primary Master Release use case.

Hi,

i also need independant release-dates for sub-releases.

Example:

• I have one major in a product.
• Every year there will be an new version of the major.
• During the year the dev-team is developing some extensions with new features.
• The extensions are released during the year for some customers.
• All features from the extension are coming to the new major
• In a timeline:
  • Q4 2015 - major version 2
  • Q1 2016 - extension 1
  • Q2 2016 - extension 2
  • Q3 2016 - extension 3
  • Q4 2016 - new major version 3 (with all the features from extesion 1,2 and 3)

So in one sentence: I need the possibility to merge a release into an other release, without losing the features in that release or setting a new release date.

I really need that!!!!!!!!

Best regards from germany.

I wonder if the disconnect is related to what you want to use master releases for. We added master releases to Aha! specifically to support a set of sub-releases which have the same release date. i.e. the defining characteristic of a master release is that it coordinates multiple sub-releases which are released together at the same time. This is common in environment where a large product is broken down into many components. Each component is developed separately, but when the product is released each component is released at the same time - thus the need to have the same release date.

It sounds like you want to use a master release for something else. Perhaps simply as a way to group related releases? Can you elaborate more on why you want to use master releases at all.

I respectfully, but strongly disagree. I think your approach is leaving a major, gaping hole for us. And as a product user, I kind of don't care what your definition use case is (I can read that myself, and have several times.) I'm asking for flexibility to do what I need. I understand how you think they should be used, but we find that concept pretty limited and useless. If you want me to instead file this again as an abstract feature request (e.g. create a method to visualize multiple product releases across products, releasing at different times, that results in a combined significant business value), then OK. But at least tell me that's what I should do.

Apologies at how curt this is, but many of your responses come across as fairly dismissive. And for us, the issue I've laid out above is pretty damn important to continuing to drive deeper adoption of Aha here. So please humor me a bit.

-Harrison

Harrison Lynch
| Sr. Director, Product Development | Consensus Corp | Office: 415.357.7611 | Mobile: 415.265.2326 | 201 Mission Street 30th Floor | San Francisco, CA 94105
[cid:23387451-D500-4885-8220-5208FBE97299]