`interscript-maps` as a gem should be able to be independently updated and released

[ronaldtse]

Without a dependency on the Ruby runtime.

The syntax of maps should be decoupled from the version of the Ruby runtime (i.e. new runtime features should not break old maps, new maps using new features should not be loaded with old runtime versions).

[webdev778]

I see one possible problem that I would like to clarify. I have one particular usecase in mind and hope to propose some solution with that usecase. Let's suppose we have 3 version sets for all repositories (so they are independently versioned only on the PATCH level). Let's say:

v2.1 (current one, after we become version independent) v2.2 (adds reversibility support, which adds a few new keywords to the DSL) v3.0 (changes the DSL in an incompatible way).

Now, let's suppose someone Gemfile contains gem "interscript", "~>2.1.0". Now we have some options:

• interscript gem contains a dependency on interscript-maps "~>2.1.0", so everything works as intended
• interscript gem contains a dependency on interscript-maps "~>2.1", which causes the client to pull interscript-maps = 2.2.0, which may contain some maps that have unsupported keywords
  • those maps don't get loaded, because they have also a new DSL keyword version "2.2", which is understood by interscript 2.1
  • question: should map writers be concerned about the minimal API version?
  • those maps fail silently (which could be a debugging nightmare)
• interscript gem contains just a dependency on interscript-maps, which causes the client to pull interscript-maps = 3.0.0, which is incompatible

Now, interscript-js doesn't have this kind of inter-dependency. But I see a possibility, that the compiler changes the compiled output while interscript-js preserves the API compatibility (just not the private API), which shouldn't warrant a major version change.

Those are the issues I'm concerned about with the independent release system. If we at least keep the MAJOR.MINOR in sync then we will be able to proactively stop situation like this in the future from happening. But perhaps I'm missing something. We could also use some internal numbers, but those internal numbers won't really translate to Gem versions. If the assumption of MAJOR.MINOR being synchronized is too much, then I would be glad to know about some other way we should approach and formalize the versioning system.

[ronaldtse]

question: should map writers be concerned about the minimal API version?

Yes. The Interscript API version should be kept separate from the software versions.

Interscript maps are not "backwards compatible": maps that use a new version cannot be used with old runtimes.

[ronaldtse]

For interscript-maps, we can have an additional number prefixed by the runtime minor version. e.g. interscript-maps '2.1.X' supports interscript versions '2.1' and above.

The use cases we need to support:

• A map has updated and we want to release that => update interscript-maps only
• Runtime/DSL has updated => update interscript and interscript-maps