Docs/contributing: Add section on how to create a new Release

[EwoutH]

Add a step-by-step guide on how to tag a new Mesa release. I have been doing this for some while, but it's good to have it documented.

Also removes the redundant script. See the link in step 1.

CC @wang-boyu and @adamamer20 for Mesa-geo en -frames.

[rht]

Also removes the redundant script. See the link in step 1.

I disagree and the situation hasn't changed since then. I thought this was already resolved by @jackiekazil . I just haven't been making PR's lately, doesn't mean that automation of doing release is no go.

[EwoutH]

Sorry but please explain to me what the added value of your 82-line script + folder is. You click this link (which is now documented with this PR) and see directly which PRs you have to label.

If the script is very dear to you we can keep it in a gist or something.

[rht]

You are repeating the same argument, which I already answered in #2047 (comment). It has a similar answer to "what's the added value of using curl <url> if I could just open the <url> in a browser and download it?".

[EwoutH]

Then explain the workflow that makes this valuable to you. Help me understand.

[rht]

I have already written the workflow in #2047 (comment).

[jackiekazil]

The links that have been added made it easy to quickly get up to speed. Thank you for those!

The script would help from a complete deployment pipeline automation perspective, which is a step towards that, even though we are not using it now. Full automation is an end goal, yes?

[rht]

Full automation is an end goal, yes?

To make it so that there are as few manual steps as possible. The release highlights still need to be manually added.

[jackiekazil]

@EwoutH, based on rht's comment -- is there a reason why we should remote it?

[EwoutH]

Personally, adding labels, cleaning up PR titles and writing the highlights are things you want to do yourself, and not automate (with LLMs or anything) yet. This is a kind of iterative process, from the moment you first press “draft release notes”.

But I understand there are different preferences in workflows. Since I will likely transfer the release management next month, I will leave it in and the next release manager can decide the usefulness of this.

[EwoutH]

Cleaned up the PR, it now only modifies contribution.md.

[tpike3]

LGTM --- Thanks for documenting this @rht; incredibly helpful!

[tpike3]

Apologies, I think I missed most of the conversation.

However, I will say philosophically, on back end management and improving and automating workflows which are typically transparent to users, I think we should aggressively explore-exploit.

I think this for two reasons, but am always open to having my mind changed. 1. As an open source project, that is contingent upon volunteers free time (at least currently) finding any efficiency is beneficial. 2. As pointed out at the last dev session by @quaquel and a known hard problem with ABMs, is how do we create an ecosystem that can evolve and stay in sync/develop together with numerous parts? (I am still intrigued by the monorepo idea.) To find solutions to hard problems to me you have to explore more aggressively.

[EwoutH]

I tend to agree with the sentiment and general principles, but in this case 85% of the work is actively making choices about what label want you an PR to give, modifying a title and what's important for the release notes. These are thing that do need value judgements and are extremely hard to automate right now (you would need SOTA LLMs that have full context and insight in every PR between two releases, and the motivation behind each of those).

For me a release is ~30 minutes work, depending on the size, of which 25 minutes is actively making choices about what to label, what to write and why.