New api version

[tim-hellhake]

Now that there are changes in the protocol will there be a new API version?

[mrstegeman]

Nope. We haven’t broken compatibility with any existing add-ons, just added new APIs. You can feature detect the new APIs at runtime.

[tim-hellhake]

But name was replaced by title.
Will the gateway still work if an addon sends name?
What would be a breaking change then?

Is there an api which indicates which features are available?
Wouldn't make it make sense to filter out addons which use features which are not available in the current gateway version?

[mrstegeman]

I kept backwards compatibility in place for the title change, so that didn’t break. A breaking change would be something that would cause existing add-one to no longer function.

You can use a try/catch require for the new modules, that’s what I’ve done in other places.

[tim-hellhake]

You can use a try/catch require for the new modules, that’s what I’ve done in other places.

Sounds a bit messy.
Nobody would expect imports to fail.

[mrstegeman]

For new add-ons, they won’t fail, given that authors will be starting with 0.9.

For existing add-ons, the authors should expect them to fail on pre-0.9, given that those APIs were not available when they created the add-on.

[tim-hellhake]

But why not simply increase the version number?
You could immediately update all max versions to 3.
The addons which use the new features can increase the min version to 3.
That's much cleaner and simpler than adding extra code for every new feature.

[mrstegeman]

We really try not to bump the API version because every single add-on would need to be updated in order to run on the new gateway version. The gateway simply will not load an add-on if support for that API version is not declared.

Would it help to provide a method in the gateway-addon packages that at least tells you the current API and package versions, and maybe even the gateway version?

[tim-hellhake]

We really try not to bump the API version because every single add-on would need to be updated in order to run on the new gateway version.

Damn, I forgot that the API version is also present in the package.json.

It looks like the current concept of the API version is broken.
It's hard to update the API version now, and it gets even harder the more users and addons you get.
At some point, the impact will be huge.
What's a versioning worth that you can't use?

I see three options:

• Pay the price once and get rid of the max versions in all addons before it's too late. If someone really needs an upper bound, he can set it in an update.
• Deprecate min/max versions and add a new property for the api version. I could also imagine a since property, which specifies the minimal version of the gateway you need.
• Freeze the current addon list and create a new one for future gateway versions.

What do you think?
If I can be of any help, please tell me.

[mrstegeman]

We're getting ready to rework the add-ons system quite a bit, since we're now adding different types of add-ons (notifiers, extensions (soon), services (soon)), and with that, we'll be bringing in a new manifest format based on the manifest.json format from WebExtensions. That would be a great opportunity to rework all of this.

We'll be asking for feedback through that process, so please weigh in once we start!

[tim-hellhake]

That sounds even better!

[mrstegeman]

This should help a tiny bit: WebThingsIO/gateway-addon-node#43