Dependency concept for extensions

[Sebastian-ubs]

User Story

1. As a user, I want to know which extensions I can install with which version of the platform so I can either install the ones that work for my current version and use them or install another program version to be able to use other extensions.
2. As a user I want to know which extensions, that depend on other extensions, will work so I know if I can use them.

• based on Design high-level versioning for extensions #661

Description
Work on a dependency / compatibility concept for extensions. How should different versions of extensions work together

1. with the platform
2. with other extensions

1. Compatibility with the platform

Looking at Thunderbird as an example: They have a minimum and maximum compatible version, using the asterisk as a wildcard. Is this what we need here as well? Or can we make sure there is only a minimum version (mostly) ever needed? And if not: how can we make sure to keep the platform and extensions compatible over time?
.

2. Compatibility between extensions

As an example thinking about a small extension that would do some little tweaking to another (let's call it the base) extension.
This would require a certain minimal version of the base extension (e.g. where this functionality was first introduced). If the base extension changes, the extension depending on it might no longer work. Depending on availability or intention there might be

• a) no follow up (extension keeps being around, people think it works, but it does not)
• b) an update of the max compatible version (so people know it will only work with the base extension until version x; obviously this max version cannot be known at the time this extension was created, but only when the base changes). Ideally including the possibility to provide a comment about the reason.
• c) the extension gets fixed / adapted (if not communicated upfront, this may take some time, meanwhile we are in situation (a) or may actively choose (b))

Doing a real change or only updating metadata in the marketplace might depend on available people to fix it.
A change in the base extension might obsolete the need for this extension. That's why "fix" is not always the best solution, but could also be (b) permanently.
One might think this is over-engineering because extension developers will anyhow keep always updating extensions along with the platform / the extension they depend on. Hopefully this is often true. But as discussed before this however will not always be the case and sometimes not even helpful.

Question: Do we need (2.) a model of compatible versions between extensions and does it have different requirements than the extensions depending on a certain platform version?

[irahopkinson]

Good issue. Since extensions already have a package.json file how about we just use the facility there for dependency (including peer dependencies). If we use semver correctly we know that a major version number could break an existing relationship. So if a extension has a minimum version dependency on a base extension (since we can't look into the future and know it is still compatible) we wouldn't expect it to necessarily keep working if the base has a breaking change to a major verion number.

[tjcouch-sil]

I agree that we should take advantage of semver and the implications it has (and possibly the dependency syntax from package.json's version strings), but I think we will muddy the waters if we directly use the fields in package.json. I think putting extensions in as dependencies in package.json will mess up npm interactions and will not give clear delineations for us to determine which dependencies are extensions and which are simply npm packages. Additionally, I expect it is possible that someone could publish an npm package and an extension from the same repo, so I'd consider the version field in package.json to be different than the version field in manifest.json (though I'd generally recommend the same value in both places unless there is some good reason to do otherwise). I'd prefer to keep npm-related versioning and dependencies to package.json and extension-related versioning and dependencies to the manifest.json.

If we are feeling particularly inspired to do so, maybe we can say manifest.json has extension stuff in it, but missing fields in manifest.json will be backed up to package.json. I dunno if I like that, though. Seems kinda nice for some stuff but annoying for other stuff. Seems nicer to have one consistent/finalized manifest.json included so we don't have to read from two files everywhere we want extension info (for example, we would have to make sure to synchronize the reading logic in Platform.Bible and in the extension server. Sounds prone to getting out of sync).

[Sebastian-ubs]

So I think the minimum version looks clear:

• an extension has a version in manifest.json and package.json, which mostly should be the same and using semver
• there would be a dependencies section listing the minimum required platform and peer extension versions.
• this would be reflected in the extension manager / marketplace and considered e.g. on updates

Now about max version:

• To me it looks like this is something that could just need to go into the extension manager / marketplace, to mark published extensions later as only compatible until a certain version.
• Default assumption would be extensions are compatible with newer versions as well.
• This would also mean min version can always be a fix version and does not use any wildcard pattern like * or ^

Open questions:

• I think we cannot expect to rely on a semver pattern only. Some change might be small from the perspective of the base extension, but still break the extension relying on it. So semver might be an indication for the developer of a dependent extension*, but will not guarantee for not breaking anything. Having the possibility to define max version in the marketplace should be sufficient to solve this I guess.

*Means they could check if adaptation is needed. Be aware that this person might or might not be available for further adaptation over time.

[Sebastian-ubs]

so I'd consider the version field in package.json to be different than the version field in manifest.json (though I'd generally recommend the same value in both places unless there is some good reason to do otherwise)

Probably we could add a check for a similar version in package.json and manifest.json on publishing the extension?

[lyonsil]

We are in the process of adding extension dependencies to manifest.json in terms of extension names (which might or might not be different then package names). For the moment it is just an empty list, but we need to use this both to determine which extensions to download and install automatically (e.g., if I want to install extension "car" and it depends on extension "tires", we need to automatically install "tires" first) and to determine the start up order of extensions (e.g., from the previous example, start extension "tires" before extension "car" so that all of "car"'s dependencies are live before "car" activates).