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.