[WIP] Add documentation for the release cycle

[AThousandShips]

Checklists for the release process

Still very much in progress but rough outlines for feedback and for the relevant teams to provide the steps for their areas

[AThousandShips]

@akien-mga Would appreciate some help on this section

[akien-mga]

Rough process dump for editor strings: https://gist.github.com/akien-mga/9357c5886e06fdff70f0499970cd4115

I'll add the process for the docs/manual later.

[AThousandShips]

Transferred and integrated these steps partially and will do some proofreading of them tomorrow! Thank you!

[akien-mga]

I updated the gist with a few fixes to the previous section, and a new section for the docs/manual update.
We'll go through that process together with @Calinou next week, so I suggest waiting for that so we can do further tweaks on the gist before integrating it in the contributing docs.

[AThousandShips]

Great! Then I'll take a look at a general new pass on this one when that's ready

[AThousandShips]

Do you have any updates on the translation process? Looking at potentially doing some work on this PR this week

[akien-mga]

The gist linked above is complete. We ran through the docs process with @Calinou and I don't recall that it required further adjustments. So you can finish integrating it.

[AThousandShips]

Great! Then I'll look at that today and tomorrow

[AThousandShips]

@mhilbrunner @skyace65 Would appreciate some help outlining these processes here

[skyace65]

This is going to be a mhilbrunner thing. I haven't done release day changes (making the new branch) before.

[mhilbrunner]

Hai. I can indeed provide at least some of these (especially the docs; translations are the big one where I lack the practical experience, although I've tried to follow along when Akien patiently explained the process to me :P)

I'm pretty swamped currently, but I'll try to find a minute to contribute in whatever form works best... maybe a PR to this PR?

Also thanks for taking the initiative and working on this, its been sorely needed for a long while.

[AThousandShips]

Thank you! And we can work out how to best provide the details, perhaps a gist? Or if someone else who is familiar with the details can help as well

But this PR will take a while to get through my own tuning and adding sections so no rush!

[Repiteo]

This step revolves around the godot-headers repo, where the master branch is updated to include the stable release's extension_api.json and gdextension_interface.h output. Thereafter, a new branch should be made and pushed upstream named after the stable release version, which is where future maintenance releases for that minor version will be pushed (if necessary). Because GHA relies on this, it should be performed before syncing the godot stable branch upstream

[AThousandShips]

Will adjust tomorrow!

[Repiteo]

Off the top of my head:

• Ensure that CHANGELOG.md is updated with content from the interactive changelog.¹ It can be mostly copied 1-1, but still necessitates a pass in each section to make sure it's properly alphabetized (though this should be fixed in the changelog repo, now that I say it out loud) & any reversion/reverted PR pairs are stripped (if and only if they occurred within the same cycle)
• Dedicated commit bumping version.py to stable (status = "dev" and docs = "<minor release version>")². The commit's content should look like this:

Bump version to 4.x-stable \o/

<maintainer writeup from the release page's blogpost for major/minor releases>

See the release page for details: https://godotengine.org/releases/4.x/

• Immediately after syncing the stable branch upstream: create a lightweight Git tag pointing to the release commit SHA & push it upstream. This MUST be done before running the stable publishing steps, as uploading the builds to the main repo relies on the tag existing. MAKE SURE you don't have a branch name that overlaps with the prospective tag, or this step will fail! It'll look like this (4.7 as an example):

git tag -f 4.7-stable 5b4e0cb0fd279832bbdd69fed5354d4e5ad26f88
git push upstream 4.7-stable

• Before any other commits/PRs are merged, standalone commit should be pushed that bumps version.py and other related files targeting the just-released version.³

Footnotes

1. godotengine/godot@3660beb ↩

2. godotengine/godot@5b4e0cb ↩

3. godotengine/godot@d0b80d5 ↩

[AThousandShips]

Updated from the outlines above, will look at adding the translation content next week and tuning some of the other sections, thank you @Repiteo!

[AThousandShips]

CC @dsnopek @BastiaanOlij any steps critical for the extension/godot-cpp side that would be good to document here?

[dsnopek]

any steps critical for the extension/godot-cpp side that would be good to document here?

It could make sense to add some notes to the release_cycle_checklists.rst for godot-cpp:

• On every -beta, -rc and 4.x.0-stable release, we update the extension_api.json and gdextension_interface.json for that Godot minor version
  • We don't do this for 4.x.1, 4.x.2, etc patch releases, because that would lock godot-cpp to requiring that specific patch release or above
  • This is has traditionally been done via a commit directly to master, without a PR (although, a handful of times it was done via a PR, usually when some other part of it needed review)
  • Here's an example.

I think that's all that would fit in with what's in the PR so far. It may be worth nothing somewhere that we don't allow changes to gdextension_interface.json in patch releases, but that doesn't seem to fit in here

[AThousandShips]

Thank you will look at integrating that and doing some restructuring today!

Edit: Will get back to this on Monday

[AThousandShips]

Integrated the rest of the translation workflow with some adjustments will do a deeper proofread of it tomorrow and look at some of the other parts of the workflow

[AThousandShips]

Did some proofreading of the translation section and it should be good to go, will take a new pass over the rest of the changes next week and try to fill in the missing areas