eclipse-platform / eclipse.platform.releng.aggregator

Aggregated repository for Eclipse Java IDE
https://www.eclipse.org/eclipse/
Eclipse Public License 2.0
30 stars 71 forks source link

Auto-assign milestones to merged PR's #2203

Open iloveeclipse opened 1 month ago

iloveeclipse commented 1 month ago

Follow up on https://github.com/eclipse-jdt/eclipse.jdt.core/discussions/2627

We should automatically assign milestones to merged PR's to simplify our life tracking which release contained which fix etc.

There are various solutions possible, see list below fro what google found:

This should be done for all eclipse SDK projects (Platform, JDT, PDE, Equinox).

Note, differently to Platform, JDT has BETA_JAVA23 milestone that should be excluded from the "automated" process.

Beside this I believe all projects should be very similar in what milestones we have, as they are created from a job during release preparation process AFAIK.

@HannesWell, @laeubi : you seem to have some experience in the github actions area, I would really appreciate if you could help here.

HannesWell commented 1 month ago

Sounds good and is probably not too difficult to implement (haven't looked into the examples yet). I can try to help with that next week (I'm away over the weekend).

laeubi commented 1 month ago

For Tycho I use is:pr is:merged no:milestone and then batch assign milestones or is:issue no:milestone is:closed.

We should automatically assign milestones to merged PR's to simplify our life tracking which release contained which fix etc.

Github also allows to see what has changed when one creates a release and can generate a list or one can generate it form the Tags created in a repository.

Beside that assigning a milestone to a closed PR is somewhat useless, a Milestones main purpose is to track what works needs to be done (or is planned) see for example https://github.com/eclipse-tycho/tycho/milestones but from my experience no one is really doing such planning, but your BETA_23 is a good example, if there is work that needs to be done until one can declare "finish" of 23 support then a milestone (e.g. Java 23 Support) would be a good choice to let people know what is left.

iloveeclipse commented 1 month ago

Beside that assigning a milestone to a closed PR is somewhat useless

There are JDT & platform committers that don't think so, me including. Also looking on the links, there are projects like theia which are also doing this, so it seem to be not useless also for other projects.

I have almost daily task to identify whether some fix or feature or bug exists / doesn't exit in a specific release. Currently this means to lookup commit in a repo, scroll up/down the history to see in which release / milestone it is included. It is tedious and wastes my time.

Milestones main purpose is to track what works needs to be done

Sure, it is one purpose, and important one. Unfortunately it is hard to "enforce" every contributor to follow every good practice, and people also do mistakes. Since this is a different topic, if you are interested, please open a discussion thread for the planning /milestones use etc.

Let's keep discussion on this ticket focused on the one concrete use case - automatically track which PR is included in which milestone.