Update specs to 2024.1

[ftomassetti]

Given all changes from now on will go towards 2024.1, we update the specs number.

We introduce BuildConfig to share a gradle configuration value with the Java codebase.

We also introduce version catalogs.

[enikao]

I'm not sure this approach works, as the contents differ for each release (e.g. PrimitiveType JSON will be gone in 2024.1).

The idea in LW-MPS (Not sure whether it works):

class LionCoreConstants_2023_1 implements ILionCoreConstants_2023_1, and adheres to 2023.1

Until now, class LionCoreConstants extends LionCoreConstants_2023_1 implements ILionCoreConstants and contained the changes we've had since 2023.1 release.
ILionCoreConstants extends ILionCoreConstants_2023_1.

Once we have 2024.1, I'll rename LionCoreConstants -> LionCoreConstants_2024_1 and have a new class LionCoreConstants extends LionCoreConstants_2024_1. LionCoreConstants_2024_1 will override getJsonType() to throw UnsupportedException.

I never access anything statically, always hand in an instance of ILionCoreConstants.

This way:

• All unchanged elements between LW releases have the same Java object identity.
• I can always decide explicitly which version I want to use.
• Using unsupported elements in any LW release throws exceptions.

[ftomassetti]

If I understand correctly ILionCoreConstants would contain methods for all the things that were created across the versions, throwing an exception when we access one not supported by that particular instance. For the sake of making an example, if we introduce in 2024.1 a date type, and then we remove it in 2025.1 we could have ILionCoreConstants_2023_1.getDate and ILionCoreConstants_2025_1.getDate throw an exception, while ILionCoreConstants_2024_1.getDate would return a proper value. Do I understand correctly?

For the time being, I wonder if we want to support 2023.1 at all in new versions of LionWeb Java. The user base is basically just us, and we can keep using previous versions of LionWeb Java until we want to move to 2024.1. Doing so will simplify the design, and postpone the problem of supporting multiple versions to the time when the user base will need retrocompatibility.
What do you think?

[enikao]

If I understand correctly ILionCoreConstants would contain methods for all the things that were created across the versions, throwing an exception when we access one not supported by that particular instance. For the sake of making an example, if we introduce in 2024.1 a date type, and then we remove it in 2025.1 we could have ILionCoreConstants_2023_1.getDate and ILionCoreConstants_2025_1.getDate throw an exception, while ILionCoreConstants_2024_1.getDate would return a proper value. Do I understand correctly?

Almost: The interface hierarchy would be:

• ILCC_2023_1
  • ILCC_2024_1
    getDate()
    • ILCC_2025_1
      • ILCC

The class hierarchy would be:

• LCC_2023_1
  • LCC_2024_1
    getDate() { return xxx; }
    • LCC_2025_1
      getDate() { throw Unsupported; }

[enikao]

So ILionCoreConstants is always the newest one, and old ones don't change.

[enikao]

For the time being, I wonder if we want to support 2023.1 at all in new versions of LionWeb Java. The user base is basically just us, and we can keep using previous versions of LionWeb Java until we want to move to 2024.1. Doing so will simplify the design, and postpone the problem of supporting multiple versions to the time when the user base will need retrocompatibility.
What do you think?

There aren't many users yet, but we could use it as training for version changes.

[ftomassetti]

Ok, let me try something to take into account support for 2023.1, as an exercise. I would aim to have a simpler structure, if I can find an acceptable solution

[ftomassetti]

One thing that came up is this: we may need to implicitly import all versions of LionCore and LionCoreBuiltins.

Consider this example, where we are using the newer serialization format but referring to a previous version of LionCore, with no languages imported.
Should this work?

{
  "serializationFormatVersion": "2024.1",
  "languages": [],
  "nodes": [
    {
      "id": "library",
      "classifier": {
        "language": "LionCore-M3",
        "version": "2023.1",
        "key": "Language"
      },
      "properties": [
        {
          "property": {
            "language": "LionCore-M3",
            "version": "2023.1",
            "key": "Language-version"
          },
          "value": "1"
        },
        ...
}

[enikao]

One thing that came up is this: we may need to implicitly import all versions of LionCore and LionCoreBuiltins.

Consider this example, where we are using the newer serialization format but referring to a previous version of LionCore, with no languages imported. Should this work?

In LionWeb-io/specification#58 we've said:

A new version might be needed if the LIonCore M3, the serialization format, or both change.

This implies that M3 and serialization version are always in sync. From this point of view, your example is invalid.

I could live with this. More interesting would be this case, i.e. mixing languages from two LW releases:

{
  "serializationFormatVersion": "2024.1",
  "languages": [],
  "nodes": [
    {
      "id": "library",
      "classifier": {
        "language": "LionCore-M3",
        "version": "2023.1",
        "key": "Language"
      },
      ...
    },
    {
      "id": "something",
      "classifier": {
        "language": "LionCore-M3",
        "version": "2024.1",
        "key": "Language"
      },
      ...
    }
  ]
}

I have a feeling we want to support that, at least for migration scenarios.

[ftomassetti]

This implies that M3 and serialization version are always in sync. From this point of view, your example is invalid.

So that would mean that either the serialization modules support serializing with all previous formats, or whenever we touch a language we are forced to migrate it to the new version of the language, in order to be serialized. Correct?

[ftomassetti]

Ok, this seems we need to go for a much more complex and comprehensive approach. I started doing some experiments and this seems very complex, so I would make this a draft PR. I will go back to this once I have enough time to dedicate to this.