nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Problem when releasing a version

Åse Nordberg

Hello community, I have questions about releases!

In one of our projects we have a couple of workflows where all of them ends up with three status in a row, all of them categorized as Done. The statuses are “Ready for production” followed by “Ready for test in production” which in turn is followed by status “Closed”.

All of these three statuses appear in the last column in all boards.

We usually work in sprints and we define an issue as “Done” when it reaches the status “Ready for production“. (We are not always able to deploy to production in the end of a sprint due to different reasons but still want to reach some kind of done in the sprint)

But it is only when an issue is changed to status “Closed” the resolution is set.

We use to release a version in Jira when all of its issues are in status “Ready for production” (and an automation rule sets all of them to status “Ready for test in production”). Everything has been working fine until this week when Jira all of a sudden says: This release contains unresolved issues . I can see its due to the fact resolution is not yet set.

Is this a new feature? Do I need to change all of the workflows? Do I have to set resolution when the issue reach “Ready for production”? Is it a big “nono” to have three status categorized as Done?

/Åse

Accepted answers

Walter Buggenhout

Hi @Åse Nordberg,

I am not sure if this is a new feature or not. I've scrolled through the release notes and the only thing related to releases I could find in recent weeks is the new capability to show JSW releases on a calendar in JWM projects.

Having said that - sprints and releases are different things. And the way you seem to manage the way you would mark issues as completed in sprint is correct: all statuses you consider as completed should indeed be mapped to the rightmost column of the board.

If it is true that a resolution is required on all issues in a release in order to be able to release it, you would have to provide a value for resolution earlier on indeed. I would try and test if this is indeed the case - to be absolutely sure that it is the missing resolution causing the issue and not the status category (also a possibility: done statuses are green). If it is the resolution field, you could consider adding a value to make it clear that development is done, but the issue isn't released. If it is about status category, just make sure your done statuses are green. If it's the last option, you would have a quick fix for the issue.

Hope this helps!

Freek van der Helm

Hello,

I am having a similar problem. My workflow is more straightforward, but the problem is the same. I have a workflow that has a Done status, I have never consciously used Resolution in my work flow.

Normally, if all issues contained in the version were of the status Done, Jira allowed me to release the version. Today for the first time this did not work. It has been about a week since my last release. Today, I am getting the following error:

Screenshot 2024-02-13 144102.png

It seems that either:

- Transitioning to the done status no longer sets the resolution as done. I don't know if it did this before, because I never used resolution.

- Releasing a version now requires resolution to be set to done instead of status.

Tomislav Tobijas

Hmm, we've been informed by one of our client the exact same thing. 🤔 (note that their instance is at least 2-3 years old)

They did not set resolution value on issues with status category "Done", and before a week or so (definitely in December last year) they could easily release versions without this warning window popping up. I too have checked product updates but couldn't find any relevant changes there. Would be great if someone from Atlassian could jump in here and check if some changes have been made in the background.

Sebastian Krzyzanowski_1kh6mn

Hello folks - I don't know when or why, but I can confirm, that the behavior behind "what is an un-/resolved issue" was changed not long ago, since we are/were using the Release Management feature quite heavily and now have to face the same problem.

Not long ago the Release Feature considered all issues set to a Status belonging to the "Done Category" as "resolved issues", even without the Resolution field beeing set:

Now the Resolution field determines whether an issue is considered "un-/resolved" upon release or not - not the Status Category!

Although I'm not completely sure, I belive this behavior might have been introduced/changed alongside with the new "Release from Kanban Board" feature (see Release a version | Jira Software Cloud | Atlassian Support):

If you are using Kanban in a company-managed project, you can release a version via the Kanban board. Click the Release menu above your board to see a list of unreleased versions.

To make this work, issues have to be moved to the "closed" column:

And "closed" issues usually have a resolution.

All of this is new - not long ago it was not clear how JIRA/Atlassian intended the Release feature to work -> whether íssues have to be "closed" before a Release or afterwards. Not long ago my team for example used to "release" issues NOT beeing closed - and used an automation rule to close those issues during/after the release!! Now JIRA/Atlassian seems to accept only closed (and resolved?) issues for a release...

All comments

Walter Buggenhout

Hi @Åse Nordberg,

Hope this helps!

Bill Sheboy

Hi @Åse Nordberg

Adding to Walter's answer...

When helping with another question recently, my testing showed issues do not need to be resolved (i.e., have a value in Resolution) to be in a released version.

Using the dialog to release the version and selecting the option to "ignore unresolved issues" leaves them assigned to the version. This can cause unexpected behaviors for teams using Kanban boards with the default sub-filter, as the issues will immediately vanish from the board.

Kind regards,
Bill

Freek van der Helm

Hello,

I am having a similar problem. My workflow is more straightforward, but the problem is the same. I have a workflow that has a Done status, I have never consciously used Resolution in my work flow.

Screenshot 2024-02-13 144102.png

It seems that either:

- Transitioning to the done status no longer sets the resolution as done. I don't know if it did this before, because I never used resolution.

- Releasing a version now requires resolution to be set to done instead of status.

Tomislav Tobijas

Hmm, we've been informed by one of our client the exact same thing. 🤔 (note that their instance is at least 2-3 years old)

alfredo.moreno

Hi guys,

We are suffering similar behaivour since 2-3 weeks ago.

Please, could we have an answer?

BR.

Åse Nordberg

Hello everybody, thanks for your answers!

I can see I'm not the only one having this problem

I won't do any changes to my workflows for now, but maybe later on.

However, I'm pretty sure that the solution for us/me is to set resolution earlier on, ie when the issue is transitioned to the first status categorized as Done. (Green)

Sebastian Krzyzanowski_1kh6mn

If you are using Kanban in a company-managed project, you can release a version via the Kanban board. Click the Release menu above your board to see a list of unreleased versions.

To make this work, issues have to be moved to the "closed" column:

And "closed" issues usually have a resolution.

Tomislav Tobijas

Quick update - this is a reply from Atlassian dev team:

We fixed the "This release contains 15 unresolved issues." messaging to show when the version has unresolved issues, rather than when the version has issues in a "not done status category". This change ensures that the "Move unresolved issues to" functionality works as the UI suggests it does.

To summarise, customers can configure setting the resolution for issues statuses if they don't want this warning to appear, or they can select "Ignore unresolved issues" to release their version.

I didn't get the straightforward answer to the initial question which was "did you change anything in the background", but I guess if you read between the lines, they did in fact make some changes which reflected in release behavior > this new popup warning window.

Roberto Anta

Same problem detected releasing version from some weeks to now.

Resolution field is not easy to change. Not bulk access. Not direct access.
How we manage the new situation: using automation rule (configured in project settings).

We set rules to set the Resolution value when the issue transitions to a "Done" status (we have two of the: Done Or Declined, but you could have, one or ten => you need a rule for each Done status):

These rules set Resolution for new Transitions to Done.

We set rules to solve manually previously done issues (again, one per each Done status):

These rules could be used manually to update previously Done issues accessing the "Actions" button when viewing the issue (the name of the available auto rules appears just below):

I hope this helps!

Nancy_hbzx5k

Whats going on with my funds

David Zamora Gutiérrez_z1muxh

Best answer so far in my opinion. They definitely changed something without letting us now, and only god knows how many of us are suffering the consequences of this stupid decission

Maya.Zgrablic

We are not using the Resolution field and it works fine for Stories by just setting them to Done. The only ones that remain resolved are the Tests that are all in Active status. Should we unlink them from the release since we are planning to reuse these tests for subsequent releases?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud