Update Arrow when the data source is changed

[p-himik]

• issues: fixes [BUG] Arrow glyph does not update #9436
• tests added / passed
• release document entry (if new feature or API change)

[bryevdv]

@p-himik just an FYI: In order to automate release processes with the new branching strategy is to keep track of PRs on milestones as well as issues (simple "time since last release" query will not do in general, will need to query things by milestone to validate proper labeling, etc.) I've added this to the 2.2 milestone. I'll be going through and adding more recent closed PRs to milestones soon, but go ahead and add milestones to future PRs yourself.

[p-himik]

@bryevdv Not sure I follow. I didn't read that discussion mainly because I'm waiting for a proper BEP.
I guess my main question is: if the milestone cannot be put there automatically for whatever reason, how can I possibly determine what to put there? And if it can be put there automatically, why does it have to be a manual process?

[p-himik]

GitHub timestamp says that I've been thinking about it for whole 5 minutes, so here's an additional thought piece. When I create a PR I cannot possibly know when it will be merged, if at all. Only the person that merges the PR into master can know what the version that will have the changes is. Is it not correct?

[bryevdv]

I should have been more clear: it should be a retrospective addition at the time of merge, that reflects what release branch the PR landed on at the time of merge, and it should match the milestone of any related issue. I don't see how that can be automated, but am open to any suggestions.

Edit: That said, the person who merges should make any adjustments. I think if the related issue has a milestone, the PR can just start off with the same.

Edit2: Perhaps some context is useful: We have tools to check to ensure that all PRs and issues are properly labeled and its an important way we have kept the tracker tamed. But we can no longer just look s PRs "since the last release" to find the PRs to check for the current release, since some of latest PRs might be on a new (unreleased) minor branch, and some might be for patch release on an old release branch. They only want to extract what PRs are specifically for "release x.y.z" is if we put the PRs in a milestone for x.y.z

[p-himik]

it should be a retrospective addition at the time of merge

This sentence is perfectly aligned with what I said - the person that merges a PR should be responsible for setting the required label.

it should match the milestone of any related issue

Doubly that - if an issue has an incorrect (outdated) label, it should be fixed at the time of merging by the same person. Simply because I do not control when and where my PRs are merged.

I think if the related issue has a milestone, the PR can just start off with the same
We have tools to check to ensure that all PRs and issues are properly labeled

What is the merit for unmerged PRs? If a PR is not merged and still has some potential for being closed without merging, why force a milestone on it?
If it's just the limitation of some particular tooling that it doesn't distinguish between merged and unmerged PRs, then maybe we should replace/modify the tooling?

They only want to extract what PRs are specifically for "release x.y.z" is if we put the PRs in a milestone for x.y.z

Please correct me if I'm wrong, but a PR should be merged only into the relevant release branch(es). Thus, after the merge you can easily tell in what release(s) a particular PR ends up. E.g. by

git tag --contains %commit-hash%

A higher-level note - the problem of finding out what new changes are in a particular release is common for all Git and not specific to GitHub. But Git itself has no milestones. How do people fare there without GitHub?

Regarding automating it - here's a discussion about it with some links to tools and examples. But no off-the-shelf solution, it seems. https://lab.civicrm.org/infra/gitlab/-/issues/3