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