[graalvm-dev] Mandrel versioning scheme

[Foivos Zakkak]

Hi all,

As we are approaching the end of the month the Mandrel team would like
to push out a new release and would appreciate your input on the
versioning scheme before that.

If we don't hear back soon we will probably proceed with the most safe
approach of using 20.1.0.1 as the version number for this release.

Thanks,
Foivos

On 16/07/2020 23:44, Oleg Šelajev wrote:
> Hi Foivos, 
>
> we've updated the page with the roadmap, not to list outdated
> information https://www.graalvm.org/docs/release-notes/version-roadmap/
>
>
> Regarding the versioning question, we're discussing this and will come
> back with thoughts. 
>
> Thanks, 
> Oleg
>
>> On 16 Jul 2020, at 16:11, Foivos Zakkak <fzakkak at redhat.com
>> <mailto:fzakkak at redhat.com>> wrote:
>>
>> Hello all,
>>
>> I would like to bring to your attention an issue that came up regarding
>> the versioning scheme of Mandrel.
>>
>> Based on the graalvm roadmap [1] (which appears to be outdated per [2])
>> the Mandrel team initially decided to follow the following version
>> scheme:
>>
>> YY.X.Z.W where YY.X.Z would be the graalVM CE version that Mandrel
>> YY.X.Z.W is based on, and W would be an incremental number for patches
>> on the Mandrel side (including backports, bug fixes, features, etc.).
>> So 20.1.0.3 would be based on GraalVM 20.1.0 CE, 20.1.1.2 would be based
>> on GraalVM 20.1.1 CE etc.
>>
>> However, according to the new roadmap [2] there will be no YY.0.1,
>> YY.1.1, and YY.2.1 CE releases only YY.0 YY.1 YY.2 and YY.3.0-3.
>> In the old roadmap [1], YY.Z.1 releases were meant to be CPU releases
>> (aligned with openJDK CPU releases), but in the new roadmap CPU patches
>> will appear in the next Minor Feature Release (e.g. in 20.2 instead of
>> 20.1.1).
>>
>> The mandrel team would like to keep its CPU releases as close as
>> possible to the openJDK CPU releases, thus it would like to stay closer
>> to the old roadmap.
>> As a result a new mandrel release is expected to come out with each
>> openJDK CPU release (or a few days later).
>> This mandrel release will be based on the latest mandrel release (which
>> will probably be aligned with the latest GraalVM CE release).
>>
>> So at this point we have a CPU release candidate that is based on
>> Mandrel 20.1.0.0 which in turn is based on GraalVM 20.1.0 CE.
>> The question is how should this Mandrel release be tagged? 20.1.0.1 or
>> 20.1.1.0 or something else?
>>
>> 20.1.0.1 makes clear that the release is based on GraalVM 20.1.0 CE and
>> there is no chance of anyone relating it to GraalVM 20.1.1 EE.
>> On the other hand if we have multiple releases e.g., 20.1.0.0, 20.1.0.1,
>> 20.1.0.2, and 20.1.0.3 there is no way to tell which of them arre CPU
>> releases.
>>
>> 20.1.1.0 makes clear that this is a CPU release but people might be
>> confused regarding its relationship to GraalVM 20.1.1 EE.
>> Another issue with this scheme is that Mandrel will probably release
>> 20.3.1 before GraalVM CE 20.3.1 so there might be some confusion there
>> as well.
>>
>> What are your thoughts?
>>
>> Regards,
>> Foivos
>>
>> [1] https://www.graalvm.org/docs/release-notes/version-roadmap/
>> [2] https://graalvm.slack.com/archives/CNBFR78F9/p1594804615255100
>>
>>
>> _______________________________________________
>> GraalVM-Dev mailing list
>> GraalVM-Dev at oss.oracle.com <mailto:GraalVM-Dev at oss.oracle.com>
>> https://oss.oracle.com/mailman/listinfo/graalvm-dev
>
-- 
Foivos Zakkak
Senior Software Engineer, R&D Middleware
Red Hat
7B40 69D9 29BA AE91 C0B3 220A 0846 BFD1 03F0 4EA1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/graalvm-dev/attachments/20200723/48622e67/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
Url : http://oss.oracle.com/pipermail/graalvm-dev/attachments/20200723/48622e67/attachment.bin