Keeping internal branches of minor/patch releases in sync with the corresponding public ones

[zakkak]

Feature request
Keeping internal branches of minor/patch releases in sync with the corresponding public ones.

Is your feature request related to a problem?
As mentioned in #3077 changes affecting minor/patch releases are not mirrored to the corresponding public branches, e.g., changes to be released in 20.3.1 are not mirrored to release/graal-vm/20.3.
This renders testing of such changes impossible prior to release.

Describe the solution you'd like.
Changes that are not CPU-related should be mirrored to the public repository.

Describe who do you think will benefit the most.
GraalVM/Mandrel users, GraalVM/Mandrel contributors, developers of libraries and frameworks which depend on GraalVM.

[gilles-duboscq]

Hi @zakkak,

Thanks for bringing this up.

At the moment the branch used to prepare the update releases are indeed not release/graal-vm/* to prevent potentially embargoed fixes from going out.

We're looking at how we can update our process to allow the separation you describe and thus be able to have most fixes for such releases available prior to the release.

[zakkak]

Hi @gilles-duboscq,

In the meantime could we please have access to the commit hash of the public repository on which the internal release branch for the next feature release is based? This would allow us to have a better view of which changes from master are expected to land in the upcoming feature release (e.g. the upcoming 20.1.0).
A possible approach would be to send an email to the graalvm-dev list stating that the next feature release will be based on the public commit abcd1234 once that's decided.

Thanks

[gilles-duboscq]

FYI, the release/graal-vm/21.1 branch is now mirrored so you can see all the backports to that branch

[zakkak]

Thanks @gilles-duboscq, that helps a lot.

Is this now the new standard or just an one off? i.e. may we close this Issue or not?

[gilles-duboscq]

For "feature" releases such as 21.1 we want to continue doing that.

However my understanding was the the original issue was about maintenance releases on other supported branches (e.g., 20.3.1 back then or 20.3.2 now).

[zakkak]

Correct, the issue is for both feature and CPU releases, so ideally we would like to have access to (the non CPU-related parts of) 20.3.2 and 19.3.6 along with 21.1.0.

[gilles-duboscq]

@ezzarghili can we do that?

[ezzarghili]

I will need evaluate what changes can we share at this point for current releases due to CPU restricted changes, we will take this in consideration for next cycle (which actually will be just 20.3.x releases).
We need to do some changes to our internal backports timelines so we still have freeze time before the release where only CPU changes (not mirrored) go in.

[ezzarghili]

Release branches for both 19.3 and 20.3 were mirrored.

[jerboaa]

Thank you very much!

[zakkak]

That's awesome! Thank you :)