Add workflow to check milestone against current version

[Isengo1989]

Problem

We do have some PRs that describe things that have yet to be released. Those are often marked with a version note but can be overseen. Also, our goal should be to describe only what has already been released.

Solution

This workflow checks all open PRs daily at X, and if a milestone is set (format -> v6.6.10.0), it compares it to the latest released version of shopware.

If the version does not match, it adds a blocked label to the PR.

If the version matches, it removes the blocked label and adds a comment mentioning the DX team.

Future Todos

If new features are described that are not released, a milestone should be set (either by developer or dx reviewer). As it is already standard for next releases.

Copilot reviewed 1 out of 1 changed files in this pull request and generated no suggestions.

[bojanrajh]

We did have cases where we wanted to update the docs before the next minor or major release (and we still could, because the label doesn't block us, it would just be a bit weird). Will there be a case where a PR has a "blocked" label and a "version" label, but shouldn't be released automatically (maybe it was targeted for that version but the docs are not ready yet)?

I'd rather go into direction of updating the default PR template and let the author decide when to merge the PR - once approved or once a specific minor/major version is released. Maybe with a new label "ready for a review" for a clearer assignment to the DX team?

[Isengo1989]

We did have cases where we wanted to update the docs before the next minor or major release (and we still could, because the label doesn't block us, it would just be a bit weird). Will there be a case where a PR has a "blocked" label and a "version" label, but shouldn't be released automatically (maybe it was targeted for that version but the docs are not ready yet)?

I'd rather go into direction of updating the default PR template and let the author decide when to merge the PR - once approved or once a specific minor/major version is released. Maybe with a new label "ready for a review" for a clearer assignment to the DX team?

It is more of a tool to keep us up to date than to restrict a merge, which still can and possibly should happen.

Currently, it's also not a question of "let the author decide if we merge" since + 100 members can merge atm 👀

A new label will probably not do much if it is not bound to an automation or trigger.

On Wednesday, we can examine the standard we want to provide in terms of "readiness" and "outlook" for the developers more closely.

Readiness meaning: A feature is only released in docs, when it is released in shopware/shopware.

Outlook meaning: A feature is always released in docs, as soon as it is scheduled for a minor/patch (not major) and tagged with an version info inline.

[Isengo1989]

Let's give it a go and disable / remove the workflow if not needed or brings too much overhead.