-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update specs to 2024.1 #155
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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; }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So ILionCoreConstants
is always the newest one, and old ones don't change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
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.
|
In LionWeb-io/specification#58 we've said:
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. |
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? |
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. |
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.