Is there an API /Tooling / Automation to creating release records?

Summary

Tycho releases approach more often and we even have bugfix releases, in 2023 there where a total of 9 releases and actually we often want to have even more.

One thing that currently hinders us and make it a bit tedious is the rather long list of manual steps involved in that process:

https://github.com/eclipse-tycho/tycho/blob/main/RELEASING.md

And we'd like to automate this, one step is creating a release record here: https://projects.eclipse.org/projects/technology.tycho/governance

As one can see we actually only ever use a very basic record especially for bugfixes for the following reasons:

1. we don't see any value in providing these there as no one seems to actually read or use that (possibly for reasons following)
2. most if not all information can better be seen from the announce text we provide from each release (example)
3. users are more used to look at Github where the sources live and github already supports a nice Release overview: https://github.com/eclipse-tycho/tycho/releases
4. Duplicating all these information in a quite old-aged web-form with many fields and buttons is quite time consuming given that there is no clear benefit for the users or the project

What is the expected correct behavior?

We like to have some API, a maven mojo (e.g. eclipse cbi) or some automated process to not have to replicate the work needed to create such release records.

One option for example would be that releases created in the Github UI are reflected as Releases in the eclipse project site as Github already has powerful options to automate things like releases: https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes

Priority

• Urgent
• High
• Medium
• Low

Severity

• Blocker
• Major
• Normal
• Low

Impact

Manual steps are error prone an tedious.

FYI @akurtakov

There is eclipsefdn/it/websites/projects.eclipse.org#146 which is more broader question whether release records in the PMI should be requirement or not.

Cross-linking also the discussion from AC mailing list: https://www.eclipse.org/lists/eclipse.org-architecture-council/msg04663.html

added IT-prioritymedium IT-severitynormal statetodo team:releng labels

removed team:releng label

added EMO label

I agree with the points that you've listed.

FWIW, the EF does use these release records. We use them, for example, in the newsletter to announce project releases. I believe that we also have a script that uses the N&N information on release records to build an aggregate N&N for the simultaneous release (but Eclipse Tycho doesn't participate directly in the simultaneous release).

Release records were more important back when we implemented the functionality. That this information can more usefully be expressed directly in the GitHub project, combined with our change from release-based reviews to annual progress reviews makes the release records far less valuable. Traditionally, we only required them for major and minor releases (because these sorts of releases required release reviews and service releases did not).

One reason why I might (very weakly) support the continued use of specifying releases in the PMI is that it acts as a means of reminding committers (simply through engagement with the PMI) that Eclipse open source projects are required per the EDP to engage in annual progress reviews. But... maybe let's just consider this to me be muttering under my breath and not put any more thought into it. AFAICT, the Eclipse Tycho project is entirely onside with regard to progress reviews.

As discussed on eclipsefdn/it/websites/projects.eclipse.org#146, harvesting this information from GitLab/GitHub is a better solution that we just haven't had an opportunity to explore fully yet.

So... the answer to the question is no. It doesn't make sense to create an API. Rather, we should decide whether or not the EF actually needs this information and -- if we believe that we do -- we should grab it from where it already exists. Can we mark this as a duplicate and carry on the conversation on eclipsefdn/it/websites/projects.eclipse.org#146?

marked this issue as related to eclipsefdn/it/websites/projects.eclipse.org#146

@wbeaton many thanks for the explanation, I wasn't aware that a discussion is already going on, sadly it seems a bit stuck (last activity before I waked up the dragon was one year ago).

Yes I thought about that someone might use the information but we are not aware of it, therefore the idea to fill the records with a bit more details in an automated way...

I'm fine with marking this as a duplicate and if you need a project to evaluate new ways let me know Tycho would be happy to help with that and be an incubator.

closed