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

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.)

  • Harrison Lynch
  • Apr 15 2016
  • Unlikely to implement
Release time frame
  • Apr 15, 2016

    Admin Response

    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.

     

  • Attach files
  • Harrison Lynch commented
    April 15, 2016 18:03

    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]

  • Admin
    Chris Waters commented
    April 15, 2016 19:07

    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.

  • Carsten Marx commented
    April 25, 2016 08:04

    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.

  • Guest commented
    May 04, 2016 18:17

    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.