Source Tagging Scheme

[zakkak]

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)

[Karm]

Q1: Proposal 1A ❌

I deem this confusing for long term maintenance, Graal 21.2.3 and Mandrel 21.2.3 would suggest being the same thing while potentially being vastly different.

Q1: Proposal 1B ✔️

I find this being the right way to proceed long term. See also comment on branching.

+1 for having mandrel prefix.

Q1: Proposal 1C ❌

In my opinion, this would be confusing for everyone especially as the time goes.

Q2: Proposal 2A ❌

Let's follow Quarkus in this aspect.

Q2: Proposal 2B ✔️

e,g, CR1, Alpha1 etc. as in Quarkus releases. All in all Alpha, Beta and CR would be all we need I suppose.

[zakkak]

Added an extra proposal (1C) for completeness. Please feel free to suggest other schemes as well, I will add them as they come.

[galderz]

Q1

Potential problem in Proposal 1B:

When all of Graal's vm-20.1.3 patches get merged in Mandrel it should bump to mandrel-20.1.3.0.

I don't think there's any guarantee that will backport of all of 20.1.3 patches into Mandrel 20.1.3.x. We might decide to not backport some, say because they're related to the Labs JDK usage (or newer JVMCI layer), which doesn't impact or we simply don't want it in Mandrel.

Then again, this is something that doesn't seem to be an issue with say OpenJDK. Red Hat builds of say 11.0.7 might not have all the fixes/patches that Oracle's 11.0.7 have? If that's not a problem for them, it shouldn't be for us.

If this is not a problem, I'm happy with 1B otherwise I'd go to 1A. 1C would be confusing for the end user, QE, for Red Hat support...etc.

Q2

Given that we want to also want to release Maven artifacts (aside from the Mandrel JDK deliverable), I'd go for same thing found in Quarkus (as Karm indicated), e.g. CR1, Alpha1...etc.

[zakkak]

I don't think there's any guarantee that will backport of all of 20.1.3 patches into Mandrel 20.1.3.x. We might decide to not backport some, say because they're related to the Labs JDK usage (or newer JVMCI layer), which doesn't impact or we simply don't want it in Mandrel.

I think this is fine, Mandrel can stay in 20.1.2.x in this case.

Then again, this is something that doesn't seem to be an issue with say OpenJDK. Red Hat builds of say 11.0.7 might not have all the fixes/patches that Oracle's 11.0.7 have? If that's not a problem for them, it shouldn't be for us.

I find this slightly confusing TBH. If we want to say that Mandrel X.Y.Z.W is Graal X.Y.Z plus W, then if X.Y.Z is the same on Mandrel and Graal it should denote the same starting point.

[zakkak]

It looks like 1B and 2B are the winners here :)

So tags are expected to look like:

• mandrel-20.1.0.1.Alpha1
• mandrel-20.1.1.5.Final
• etc.