You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In context of oracle/graal#2764 (comment) would it be possible to automate this through this issuelabeler project? Whenever a PR gets merged perhaps look for a specific file within the repo to know the "next release version" and use that value to set the Milestone of that merged PR to this value? If setting the milestone isn't doable then perhaps add a "Fix version: the-version" kind of label? If this works, then maybe it can even be extended to do this same thing on issues that get closed when the corresponding PR is closed?
Of course, someone will have to maintain that file containing the "next project version" and ensure that on every release it is up to date. Perhaps allow the file to be configurable and some regex that determines how to "find" a version in that file, so that existing project artifacts (like a pom.xml or in case of mx builds their equivalent file) can be used to infer the version?
P.S: I've no idea if this is even in the scope of this project, but I thought I'll just go ahead and ask :)
The text was updated successfully, but these errors were encountered:
sorry, completely missed this one - what you write is definitely possible; but we would need to consider put that in a separate flow/script - but yes, very doable.
about "marker" for what is "next" I would instead of a text file consider if just fetching last N milestones and pick the one that has "[NEXT]" or similar 'tag' in the description.
In context of oracle/graal#2764 (comment) would it be possible to automate this through this issuelabeler project? Whenever a PR gets merged perhaps look for a specific file within the repo to know the "next release version" and use that value to set the Milestone of that merged PR to this value? If setting the milestone isn't doable then perhaps add a "Fix version: the-version" kind of label? If this works, then maybe it can even be extended to do this same thing on issues that get closed when the corresponding PR is closed?
Of course, someone will have to maintain that file containing the "next project version" and ensure that on every release it is up to date. Perhaps allow the file to be configurable and some regex that determines how to "find" a version in that file, so that existing project artifacts (like a pom.xml or in case of mx builds their equivalent file) can be used to infer the version?
P.S: I've no idea if this is even in the scope of this project, but I thought I'll just go ahead and ask :)
The text was updated successfully, but these errors were encountered: