Mandrel's current version is developing on branch 20.1 which is based on Graal's 20.1 branch on tag vm-20.1.0.

Facts

• Mandrel is based on Graal releases (potentially adding some backports, bug fixes, etc. on top of them)
• Mandrel is being built using upstream OpenJDK instead of labs-OpenJDK
• Mandrel (like Graal) is sensitive to OpenJDK changes (thus its builds are tightly coupled to the OpenJDK version)

Q1: So if we were to release a Mandrel package today what tag should we use for the release?

Proposal 1A

mandrel-20.1.x, where 20.1 indicates the Graal feature release this Mandrel version is based on and x is an incremental number denoting different Mandrel releases.

Main disadvantage:
There is no way to tell how mandrel-20.1.5 compares to Graal's vm-20.1.3? (which one is newer? is bug X that was fixed in Graal's vm-20.1.3 fixed in mandrel-20.1.5 or not? etc.)

Proposal 1B

mandrel-20.1.2.x, where 20.1.2 indicates the Graal feature release this Mandrel version is based on and x is an incremental number denoting different Mandrel releases.

In this case mandrel-20.1.2.5 might contain patches from Graal's vm-20.1.3 but it shouldn't contain all of them. When all of Graal's vm-20.1.3 patches get merged in Mandrel it should bump to mandrel-20.1.3.0.

Proposal 1C

mandrel-X.Y.Z where X.Y.Z follows semantic versioning (or some other convention) and is totally different from Graal's version. e.g. mandrel-1.2.1 could be based on Graal's vm-20.1.3 tag and mandrel 1.1.1could be bassed on Graal'svm-19.3.2` tag.

Main disadvantage:
We need to use a table to map mandrel releases to the corresponding Graal releases. Would possibly make sense if Mandrel was to decouple from Graal, which is not desired though.

Reasoning behind mandrel- prefix

Since https://github.com/graalvm/mandrel/ is a fork of https://github.com/oracle/graal using the mandrel- prefix makes it easier to work with both git remotes (something very common among Mandrel developers) and filter the tags

Q2: Suffix

Assuming we want to make pre-releases as well, how should we annotate them?

Proposal 2A

Use a single suffix like -pre -alpha etc.

Proposal 2B

Use more than one suffixes to indicate different pre-release kinds, e.g. -pre -alpha -beta -cr (following https://en.wikipedia.org/wiki/Software_release_life_cycle)