Hi, As part of preparing the 1.14.3 release, I observed that there were around 200 JIRA issues with fixVersion 1.14.3 that were unresolved (after blocking issues had been dealt with). Further cleanup resulted in removing fixVersion 1.14.3 from most of these and we are left with [1] - these are the tickets that rolled over to 1.14.4.
The disassociated issues broadly fell into following categories: * test infrastructure / stability related (these can be found by label) * stale tickets (can also be found by label) * tickets w/o label that pertain to addition of features that don't fit into or don't have to go into patch release I wanted to bring this up so that we can potentially come up with better guidance for use of the fixVersion field, since it is important for managing releases [2]. Manual cleanup as done in this case isn't desirable. A few thoughts: * In most cases, it is not necessary to set fixVersion upfront. Instead, we can set it when the issue is actually resolved, and set it for all versions/branches for which a backport occured after the changes are merged * How to know where to backport? "Affect versions" seems to be the right field to use for that purpose. While resolving an issue for master it can guide backporting. * What if an issue should block a release? The priority of the issue should be blocker. Blockers are low cardinality and need to be fixed before release. So that would be the case where fixVersion is set upfront. Thanks, Thomas [1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20Flink%20and%20fixVersion%20%3D%201.14.4%20and%20resolution%20%3D%20Unresolved%20 [2] https://cwiki.apache.org/confluence/display/FLINK/Creating+a+Flink+Release
