Overloading fixVersion shouldn't be a problem. IIRC you can:
- bulk update
- Merge versions:
https://support.atlassian.com/jira-work-management/docs/view-and-manage-a-projects-versions/#Merge-versions
We just need the permissions for jira to allow us to do it.
Regards
On 10/5/22 3:02, Mick Semb Wever wrote:
Thus anything unresolved flagged 4.1-alpha would be a blocker for
that, same for beta and rc. When the tickets are closed, we switch
them to FixVersion 4.1; I don't see there being much value in
knowing in the future if a ticket is fixed during the alpha, beta,
or rc phases by using the above as resolved FixVersions.
Users might want to know this distinction?
Do we want parity between CHANGES.txt and jira fixVersions?
This approach potentially breaks down if we have any final
blockers on 4.1 ga, but could just cycle through 4.1-rc until it's
all clear.
What do we do for a blocker to any other version, e.g. say there's a
blocker to 4.0.5? (As has been discussed on slack, the priority and
severity fields don't really work for us here.)
> We have done similar in the past and if something is a blocker it
means it will be in that version before it is released
Jeremiah, around when was this? I can see that it makes sense (works
in theory), but trying to correct fixVersions in jira post release can
be quite the headache, without having to reach out to people to
understand if something is intentional or a mistake. So long as
there's a way to bulk change issues after a release I am happy.
