Setting Up a Version Hierarchy

How can I identify the so-called committed version in the database? I've browsed to most of the tables trying to find information about the version hierarchy, but no luck so far...

Hello,

is it possible to set a master version for a few different projekt versions?

Thank you for your help.

How do I configure Greenhopper to display versions in a descending order. I would like my most current sprint to appear at the top.

I have tried many times to configure this and I cannot figure out how to do it for the life of me... please help!

Thanks in advance! 

I've got the same problem as David described - I need to reorder versions (they appear in reverse order on versions panel though are displayed correctly in Add versions window).

Would be thankful for any advice.

Is there any way to do the following:

I have 2 dev teams, we'll call them A and B. Each one has their own sprint, which we set up with a parent Fix Version of 'Sprint 3' and Fix Versions of 'Sprint 3A' and 'Sprint 3B' respectively. Usually, this works fine because at the end of Sprint 3, all code is released, so all 3 Fix Versions can be marked as released. But what if team B happens to be working on a couple of issues in a branch that will be done as part of our sprint cycle, but will not actually be released until a few other issues are completed in the next sprint (Sprint 4). AFAIK, when Sprint 3 is released, I have to use the release feature to mark Sprint 3, Sprint 3A and Sprint 3B released. Thus the 2 issues that were branched and therefore not released as part of Sprint 3 are now incorrectly marked as released. The other option is to not mark Sprint 3B as released, but then that wouldn't be correct for all the issues that did get released as part of that sprint.

Am I using GreenHopper wrongly by tieing sprint cycles to Fix Versions? Is there a way to do the above?

I am unable to edit the parent field for any of the versions at right - the pencil icon does not show up... Ideas?

Using Jira OnDemand. 

How do I setup the default issue screen such that when I enter a version in the fix version field, it's parent is also populated in that field? Currently if I enter Sprint1, I want the Milestone (it's parent) also populated so that when I look at the planning view I can see all issues in the Milestone (Sprint 1, 2 3). But this doesn't happen. 

Oddly, this is the behavior when I create new sub task from the submenu of any story in agile view but I want consistent behavior no matter how I create the issue.

I have found that if you use the "+Create Issue" from the main menu bar, the association to the parent version is not made. If you use the "+ New Card" link from your Task Board, Planning Board, etc..., it will include the parent version when creating the issue.

How do we handle the situation where we have one sprint that spans two versions?

We have Sprint X which includes the release of Version 1.0, and also has a couple of stories relating to Version 2.0.

Is it possible to create two "Sprint X" sprints, one for V1 and one for V2? 

There's no way for me to edit the parent value – when I hover over that in the Planning Board view, I don't get the ability to edit that.

If the Classic Boards are going away (we get the message saying no more improvements..use the Rapid Boards), how do we set the start and end dates and manage parents? Currently, the JIRA Agile left hand option shows all classic. And the Version management screen doesn't have these options. So, if we are using the boards, how do we do this?

In conjunction with the Aug 16th comment, I, too, don't see a way, even as an admin, to setup version hierarchy except in the classic boards. It seems that this would be something made available in the general Manage Versions area.

I'm also perplexed as to the value as I cannot seem to determine how to use it for reporting. If I could figure out the reporting, it would help us greatly –  issues associated with a parent version as it would give us full release notes or time tracking/invoicing as child versions are often sprints – that's another story where we would like the ability to have sprints as versions.  Or child versions are minor releases and the parent is a major release.

Either way, without the reporting, I am perplexed with the value.  Can anyone provide guidance on reporting capabilities?

Hi,

"For example, you may wish to group your sprints as milestone versions..."

is it possible  to set the parent version by sprints, created in Scrum Board ?

This sprints are not shown  neither in classic planning board, nor in tab version of project.

Greenhopper v.6.0.2

Thanks

Hi,

if the Classic Board is not supported anymore how can I build a version hierarchy? This is a very important element in our environment to show burndown and burnup charts on different levels e.g. Product has several Releases has several Iterations.

Thanks

With the new versions feature on the Rapid boards, do they respect version hierarchy, particularly in the version report?  A great feature would be a report on "all versions"  

"Version hierarchy is not supported in JIRA..."

Hmm. How is it then, that in Classic mode we can create hierarchies of versions? Greenhopper was able to implement version hierarchies in the past, so why not now?

Greg, as per my comments above, the original implementation in Classic Boards was not supported by JIRA and caused all sorts of problems. If - and when - JIRA implements hierarchy of versions, we will obviously revisit their support in GreenHopper.

Regards

Tom Kotecki

Product Manager, GreenHopper

Tom, I believe what you are missing is that your Greenhopper customers have been using the version hierarchy provided by Greenhopper with the classic boards and it is still a need when managing projects from a scrum or kanban perspective.  Thus, we are asking that Greenhopper work with the JIRA team to implement version hierarchy to allow for continued support of this feature in Greenhopper going forward.

This is similar to have version begin, end, and release dates that are required for Greenhopper classic gadgets that are again used by customers because the agile gadgets are based on version and require a begin and end date to show proper burn up and statistics. 

These features would benefit JIRA as they are common features in version management and they would benefit Greenhopper in supporting existing functionality but with the new boards. 

To continue to deprecate features without any replacement has continued to be very frustrating and extremely intrusive to the processes and reporting that we have in place and am assuming many other customers have in place.

So, we are saying for Greenhopper to work WITH JIRA to provide this support and both products benefit; and, you can continue to stay on the path of the new boards without removing functionality that provides value-add to customer processes - whether they are for development, implementations, marketing, etc.  It's not acceptable to put the burden on JIRA to say "whenever they provide it, we'll consider it".  That is not working together; that is staying in your silos and not trying to show value in the integration of the products.  Remember, Greenhopper cannot work without JIRA; JIRA can work without Greenhopper. The customer, however, gains much more value by the two teams showing the greater value when using the two in conjunction.

PLEASE work together on common goals and features, that benefit both and provide even more value to the customer. Don't keep removing features without an equal, and possibly even better, replacement.

I am very concerned that this function seems to be removed. Having a more substantial backlog it is obviously a great value being able to structure your backlog into several categories gaining an overview of the complete backlog.

Does anyone have a SQL query to pull the version hierarchies?

1) Since the only way to have version hierarchy and component hierarchy is to use Classic Boards, I'm sticking with them . I cannot understand why these two crucial features are not included in new greenhopper boards.

2) for the life of me I do not understand why we cannot have more than one sprint active on the same time in one board . Maybe I'm not thinkin in a traditional fashion, but I'd need to have several teams running several sprints on the same time. so imagine 3 teams running 3 sprints = 9 active sprints, that's the only way I see how to manage a 30-40 feature roadmap using sprints. 

 Why is this not implemented or what am I missing?