[Development] Closing issues automatically with new keyword

[Shawn Rutledge]

> On 10 Aug 2018, at 15:14, Oswald Buddenhagen <oswald.buddenhagen at qt.io> wrote:
> 
> On Fri, Aug 10, 2018 at 02:42:59PM +0200, Shawn Rutledge wrote:
>> On 10 Aug 2018, at 12:07, Oswald Buddenhagen <Oswald.Buddenhagen at qt.io> wrote:
>>> so now i think the hook/intergration should just set the fix version to
>>> the target branch name. yes, that implies that we should have the
>>> version "dev" in jira.
>> 
>> Why?  I think you can check the tags in git and find out that the highest numbered release was 5.11.1 so far, so dev has to be 5.12?  (until Qt 6 anyway)  And Jira knows which future versions are not released yet.  So when I mark fixed a bug that I fixed on dev, manually, I choose 5.12 alpha, because that’s not released yet.  I’d think the script could that too.
>> 
> firstly, adding a git query to the hook complicates it and reduces its
> reliability.
> 
> secondly, as your own caveat highlights, you need to encode and maintain
> policy in the script to make that work.

Starting to use the Fixes: tag at all is a policy, and writing code that reacts to it amounts to encoding a policy.  It’s not the first script which does something like that.

> thirdly, your proposed heuristics are wrong, because there is a window
> of time where changes integrated into dev do *not* target the next minor
> release (or a pre-release thereof): the time between the final downmerge
> form dev and the actual release.

The window between the first creation of a new branch (on Monday) and the final merge from dev to that branch (a week from Monday) is more of a concern; during that time we have a 5.12 branch (assuming we check the highest branch rather than tag) but changes to dev are still for 5.12.

Maybe read .qmake.conf then?