Backport data partition increase and disk rebuilding for 2025.3.1

[yfyf]

I created a release/2025.3.1 branch to be able to target the specific release these patches target (instead of the release/2025.3.x branch, which actually does not need patching)

[knuton]

I created a release/2025.3.1 branch to be able to target the specific release these patches target (instead of the release/2025.3.x branch, which actually does not need patching)

Shall we rename them something else to avoid confusion with actual release branches?

disk/...?

[yfyf]

I created a release/2025.3.1 branch to be able to target the specific release these patches target (instead of the release/2025.3.x branch, which actually does not need patching)

Shall we rename them something else to avoid confusion with actual release branches?

disk/...?

Not sure, I think that would add further confusion, because ideally the disk should match the release. Having disk/... branches would mean that some release disks are based on release/ branches and some on disk/ branches? Or, alternatively, that each release has a duplicate disk/ branch. It's easy to see from the git history that tag != branch (so e.g. tag 2025.3.1 != release/2025.3.1). Also, here the changes are purely testing / disk related, they do not modify what-would-be-released (i.e. uploaded to dist server) at all. This is not the case in #315, hence why it gets it's own tag with a distinct suffix (-DISK).

[knuton]

Not sure, I think that would add further confusion, because ideally the disk should match the release. Having disk/... branches would mean that some release disks are based on release/ branches and some on disk/ branches? Or, alternatively, that each release has a duplicate disk/ branch. It's easy to see from the git history that tag != branch (so e.g. tag 2025.3.1 != release/2025.3.1). Also, here the changes are purely testing / disk related, they do not modify what-would-be-released (i.e. uploaded to dist server) at all.

I don't fully understand. I was only thinking of a disk/... branch for the legacy backports, instead of the release/2025.3.1 branch for example.

My concern with having both release/2025.3.x and release/2025.3.1 is that it would be easy to confuse the two (conceptually or by typo).

[yfyf]

I don't fully understand. I was only thinking of a disk/... branch for the legacy backports, instead of the release/2025.3.1 branch for example.

OK, we can make a disk/$VER branch, but then I probably should create one for the other versions with backports too to keep it consistent. Which, I guess, would mean all versions so far, since (I think) all of them received backported fixes.

The logic for figuring out how (from what commit) a release disk of version $VER was built will then be:

• check if a disk/$VER branch exists - if it does, that's it
• otherwise, it was built from the $VER tag as part of a regular release

[yfyf]

Changed target branch to disk/2025.3.1