Branching and mirroring scheme

[zakkak]

Graal's approach

Graal uses the master branch for development and creates a new release/graal-vm/X.Y branch for each feature release.

Graal's roadmap

In Graal's versioning scheme in X.Y.Z:

• X indicates the year of the release (e.g. 19 for 2019)
• Y indicates the feature release (which are released quarterly so there are 4 each year thus Y is in the range 0-3)
• Z is an incremental number for patch releases.

Note however that in https://github.com/graalvm/graalvm-ce-builds/tags there is no 19.3.3 release, while there is a 19.3.0.2 that doesn't match the above scheme.

Mandrel

Current state

We are currently syncing Mandrel's master branch with Graal's master once per day, and we have mirrored release/graal-vm/20.1 at tag vm-20.1.0 in 20.1. Mandrel's 20.1 differs:

• from tag vm-20.1.0 in that it contains some backports (see oracle/graal@vm-20.1.0...graalvm:20.1)
• from branch release/graal-vm/20.1 in that it contains the above backports and it doesn't contain commits pushed after tag vm-20.1.0 (see oracle@9372629)

Additionally we are keeping an up to date mirror of Graal branches of interest in branches prefixed with oracle-, e.g. oracle-20.1 is a mirror of Graal's release/graal-vm/20.1 branch.

(Potential) Issues with current state:

1. Since both 20.1.1 and 20.1.2 are on the same Graal branch (20.1) we cannot keep working on Mandrel's 20.1.1+ version while testing out 20.1.2. Once we pull Graal's changes from 20.1 they are now in our 20.1.1+ version, while they should probably be in our 20.1.2+ version (for versioning please see Source Tagging Scheme #39)
2. There is no easy way to filter release branches (usefull in CI pipelines). If we name our branches mandrel-20.1 or release/mandrel/20.1 or similar then we can easily add filters in our CI pipelines.

[Karm]

I would like us to remain as close as possible to the Graal's scheme, i.e. having x.y.z for year.quarterly update.patch release. In addition, we need to add our own qualifier, making it: x.y.z.m for year.quarterly update.patch release.mandrel patch release.

I am convinced the goal should be keeping us as close to Graal's releases as possible long-term. Differences in backported patches and updates will be marked with our mandrel patch release appended to the Graal version.

Ad branches, I support having mandrel-* branches to make it possible to organize releases and CI better.

[zakkak]

Please refrain from discussing versions in this issue. Let's try to focus only on branches and how/when they should be created.

[galderz]

@zakkak Maybe we need major.minor.micro branches to handle this? So, mandrel-20.1.1 branch, mandrel-20.1.2 branch...etc. We'd need some kind of prefix/suffix to potentially differentiate from tags, or you name the tags with some prefix/suffix.

One possible suffix for the branches could be u, e.g. mandrel-20.1.1u meaning u for update (kinda like what jdk does with jdk11u), or dev, e.g. mandrel-20.1.1.dev?

[zakkak]

I prefer keeping the tags clean and going for mandrel/20.1.1 or similar for branches.

[galderz]

@zakkak @jerboaa made an interesting point in #27 (comment). Keeping branches major.minor and going along with the progress in the oracle graal micros might be less pain in the long term.

[zakkak]

So current consensus seems to be:

1. Prefix mandrel branches with mandrel/ , e.g. mandrel/20.1
2. Mandrel branches are based on graal feature releases (e.g. branch release/graalvm-vm/20.1) and not release tags like vm-20.1.0.
3. Prefix mandrel tags with mandrel-, e.g. mandrel-20.1.0

[jerboaa]

So current consensus seems to be:

1. Prefix mandrel branches with `mandrel/` , e.g. `mandrel/20.1`

2. Mandrel branches are based on graal feature releases (e.g. branch `release/graalvm-vm/20.1`) and not release tags like `vm-20.1.0`.

3. Prefix mandrel tags with `mandrel-`, e.g. `mandrel-20.1.0`

Seems sensible. I'd suggest to name the tag mandrel-20.1.0-something if it's 20.1.0 graal vm based, then change to mandrel-20.1.1-something for a 20.1.1-based graal vm. Both tags branch off a 20.1 release branch. Thoughts?

[zakkak]

@jerboaa tags are discussed here #39 and what you say sounds like proposal 1B, so I think we are in line :)

[zakkak]

According to the discussions in this thread we should:

• Prefix mandrel branches with mandrel/ , e.g. mandrel/20.1
• Base mandrel branches on graal feature releases (e.g. branch release/graalvm-vm/20.1) and not release tags like vm-20.1.0.