What does Language.version mean semantically?

[enikao]

In #92, we decided to have a version property in Language. Which semantic meaning does that version entail?

--> Decision: We chose option B: any string. Thus semantics are only about identity and language versions being related to each other.

Rationale:

• We don't want to burden LIonWeb with all aspects of versioning and migration.
• LIonWeb should support migration. We do this by having a version for both the language and meta-pointer.
• Fully automated, generic migration is not even possible in one specific implementation, even less so in an implementation-agnostic manner.
• We expect concrete LIonWeb-based systems to impose stricter limitations on the version. As each system is under some kind of common control, we can ensure all parts adhere and understand these limitations (e.g. "only linearly increasing integers as version" for MPS-based systems).

Possible semantic meanings

• For artifacts (e.g. Maven or npm packages), versions state something about compatibility.
  E.g. "I need X in version 1.2, but have version 1.2.1. Should that work?"
• In combination with SemVer, versions enable dependency conflict resolution.
  E.g. "I need both X and Y. X needs Z in version >= 2.3, X needs Z in version < 3. Which version of Z shall I use?"
• In MPS (and e.g. DB schemas), versions are mainly used for migration.
  E.g. "My instance model uses language X in version 5, but the deployed version of X is version 7. How do I need to modify my instance model to adhere to X@v7?"
• Language "A@vX" and "A@vY" are somehow related, i.e. they are not completely different languages.
  E.g. We assume language X@v4 and X@v7 are fundamentally about the same domain, and contain mostly the same elements.
  This is a weak assumption: Technically, the intersection between elements from X@v4 and X@v7 could be empty. However, that would be a weird usage of language X.
• Version "1.2.1-alpha" says something about maturity.
• Language "[email protected]" is the identity of that specific language version.

Considerations

• Do we version single languages or plugins/installations/releases?
  --> assumption: Only languages, plugins/installations/releases are out of scope (at least for now)
• Integers for versions imply intuitive total order (humans should understand "is this version older than that version")
• Strings in versions can be useful, e.g. "MyLib-v1.2-trialEast" vs. "MyLib-v1.2-trialWest"
• In case of releases on maintenance branches, migration needs to know about compatibility (see migration example below)
• We need more than total order of migration: We need to know if there is a gap, so we have to run multiple migrations
• A migration can also run if it knows the version from which the migration starts and the version to which it migrates. Then the version itself does not need inherent order.

Options for Language.version contents:

A: just integer

Pro:

• Intuitive total order
• Easy to reference
• Supports automated migration

Con:

• Cannot handle migration case
• Limits specialized use cases

B: any string

Pro:

• Supports any use case
• Easy to reference

Con:

• Does not support automated migration

C: technically any string, but should be an integer

Pro:

• Can make a default assumption to be an integer, then all pros of option A apply
• Supports specialized use cases
• Easy to reference

Con:

• Lots of room for interpretation
• Automated migration not always supported

D: list of integers, effectively "a.b.c" segmented version number

Pro:

• Establishes total order, even for edge cases
• Supports automated migration even for edge cases

Con:

• Lots of additional complexity to support edge cases
• Each reference to a language (meta-pointers) need to contain the list of integers

E: dot-separated string, effectively "a.b.c" segmented version number

Pro:

• As long as the format is correct, all pros of option D apply
• Easy to reference

Con:

• Ambiguity if format is screwed up, or in versioning edge cases (e.g. "is v8.1 and 8.1.0 the same?")
• Lots of additional complexity to support edge cases

E: Mention both the previous and the current version

Examples

Experiment

Assumption: language.version is a simple integer

Scenario: We have a language Trees@v1, and start two experiments in parallel how to continue.
Both experiments change the language, so we have two independent Trees@v2 variants.
Eventually, we want to shut down one of the experiments, or integrate both of them.

Language Trees
  version: 1

concept Tree
  property height: integer

experiment A:

Language Trees
  version: 2

concept Tree
  property height: integer
  property leafColor: string

experiment B:

Language Trees
  version: 2

concept Tree
  property height: integer
  property leafNumber: integer

Maintenance

Assumption: language.version is a simple integer

Scenario: A long time ago, we published our software release r1.12, containing Trees@v8.
Since then, we published more releases:

• r2.0 contained Trees@v9
• (big gap with more releases and language versions)
• r3.4 contained Trees@v26

Each installed release executes the migrations at the customers.

For some customers, we provide maintenance releases of r1.12.
For r1.12.7, we have to adjust our Trees language. So Trees@v8 of r1.12 becomes Trees@v9 of r1.12.7

Now we have two different Trees@v9 languages: One from r2.0, one from r1.12.7.
This is not a problem as long as they never mix.

However, one customer moved from r1.12 to r1.12.7, and now wants to move to the latest r3.4.
We provide a migration from Trees@v9[r1.12.7] to Trees@v10.

Now, we have two different migrations from Trees@v9 to Trees@v10.
If the instances only stored an integer for the used Trees version, we cannot distinguish whether they came from r1.12.7 or r2.0.

old release -> r2.0:

Language Trees
  version: 9

concept Tree
  property height: integer
  property colorOfLeafs: string

main branch -> r3.4:

Language Trees
  version: 26

concept Tree
  property height: integer
  property leafColor: string

maintenance branch -> r1.12:

Language Trees
  version: 8

concept Tree
  property height: integer

maintenance branch +1 -> r1.12.7:

Language Trees
  version: 9

concept Tree
  property height: integer
  property leafNumber: integer

[enikao]

I updated the original issue above with our decision: Option B (any string)