doc: update release-process.md

[glozow]

While doing various release process things for the first time, I noticed some of our docs are outdated and/or confusing.

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	achow101
Concept ACK	pinheadmz, hebasto

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

No conflicts as of last run.

[achow101]

In the "Commit the detached codesign payloads" section, could also mention that only one person should rm -rf ./*, or maybe just change that to rm for the set of sigs being added.

Also the commit titling scheme we're using is now something like <version>: win signature for <rc or final> rather than point to ...

[achow101]

Should also include the command git checkout --orphan <version> for creating the new detached sigs branch for a major release.

[pinheadmz]

concept ACK

I was also confused by the code signing step.

[glozow]

In the "Commit the detached codesign payloads" section, could also mention that only one person should rm -rf ./*, or maybe just change that to rm for the set of sigs being added.

I made 2 separate steps for each signer, since they'll be different people.

Also the commit titling scheme we're using is now something like <version>: win signature for <rc or final> rather than point to ...

Wrote scheme like this

[achow101]

ACK 635d16a

[hebasto]

Here's some historical context regarding translation related changes suggested in this PR.

Basically, during a release process, there are two kind of operations namely (1) generating an updated resource file and uploading it to the Transifex website and (2) downloading prepared translations from the Transifex website and merging them into this repository.

The first kind involves running make -C src translate command. The second one uses update-translations.py script from the bitcoin-maintainer-tools repository, which in turn relies on Transifex's command-line tx client.

In the past, release maintainers performed all these steps by themselves. Then the process became more involved, requiring an additional interaction between a release maintainer and a developer who conducts translation-related stages.

During the v26.0 release, @fanquake suggested (offline) to fetch translations from the Transifex website just before branching a version branch off. That would allow to keep translations in the master branch updated with no extra efforts.

This PR goes further and proposes skipping translation fetching for every release candidate.

FWIW, the v27.0 release is following the translation handling process as this PR suggests.

The benefit of a new approach is less burden on a release maintainer.

However, I can see a couple of drawbacks as well:

1. Translators have a shorter period to work on translations. Effectively, it starts at string freeze and ends at branching off, which usually lasts for a month.

2. If a translatable string is modified after branching off, it won't be translated in the release binary.

Being a translator allows me to assume that a month is enough even for a single person assuming they work on a single translation. Also we heavy exploit the "Translation Memory" Transifex feature, which effectively is a cache allowing to reuse translations from the previous releases.

The second case might be considered as a very rare event.

Anyway, this change in the release process deserves an announcement for translators on the Transifex website.

cc translation-involved people: @luke-jr @laanwj

[glozow]

Thanks for the context @hebasto. I felt that it was appropriate to move from "before every release candidate" to "before every major or minor release"(EDIT: correction, "before branch-off") because

• I didn't observe that translations were being updated per release candidate.
• It made more sense to me that it'd be per release instead of per release candidate since, as you say, changes in between rcs should be very rare and we would largely have control over this.
• As you mentioned, translations were added before branch off this time.

Translators have a shorter period to work on translations. Effectively, it starts at string freeze and ends at branching off, which usually lasts for a month.

In practice, is there a large time difference between branch off and the first release candidate?

I made this change because it seemed like more accurate documentation, definitely not as an attempt to make a controversial alteration the release process. I don't feel strongly and am happy to remove that change.

[hebasto]

I made this change because it seemed like more accurate documentation, definitely not as an attempt to make a controversial alteration the release process. I don't feel strongly and am happy to remove that change.

To clarify my previous comment, I do lean to ACK the suggested changes.

[glozow]

(Yay v26.1) I have a couple more things for the last section, and then will take out of draft.

[achow101]

I think the "Update repositories and websites for new version" section could be split into 2 distinct steps of update the website, then update the packaging repos. Apparently flathub polls the website for new releases and their bot will automatically open a pr to the flathub repo with the new version hashes. So that step must be done after the website is updated.

[glozow]

I think the "Update repositories and websites for new version" section could be split into 2 distinct steps

Done, I split into website updates and everything else

[achow101]

ACK 1ea8674

[hebasto]

Thanks for the context @hebasto. I felt that it was appropriate to move from "before every release candidate" to "before every major or minor release"(EDIT: correction, "before branch-off") because

• I didn't observe that translations were being updated per release candidate.

It happens, but very seldom. We can really ignore them as it simplifies the release process significantly.

• It made more sense to me that it'd be per release instead of per release candidate since, as you say, changes in between rcs should be very rare and we would largely have control over this.

• As you mentioned, translations were added before branch off this time.

However, I think we have to update translations for minor releases.

cc @laanwj

Translators have a shorter period to work on translations. Effectively, it starts at string freeze and ends at branching off, which usually lasts for a month.

In practice, is there a large time difference between branch off and the first release candidate?

Not at all :)

[achow101]

Went ahead with merging this since the vast majority of the changes here are correct and useful. It seems like there are still some questions related to the translations, but I think we can document those later when it becomes apparent that what we're actually doing diverges from the doc.