03 Plugin manifest file convention

It is possible for users to be notified through Studio of an updated plugin that is made available on the SDL Appstore.  In order for this to work effectively it is important that all developers who list their plugins on the Store follow a particular convention.  The reason for needing an agreed convention is that there is a strong connection between the pluginpackage.manifest information and the plugin plugin record from the Store. In order to have a better user experience (read: for this to work!) on the AppStore website we have put in place some conventions, which will be described bellow.

Description

Is important that the Description from the manifest file is meaningful.  This will be seen in the plugin manager and will be used as we continue to develop the integration of the AppStore into Studio.

Plugin name

The plugin name from the manifest file should match the name of the plugin from the AppStore.  Aside from the obvious inconsistency the notifications will not work if this doesn't match.

Incorrect

Pluginpackage.manifest.xml

AppStore web site

Correct

This change will also make it easier for users to identify the app names in the plugin manager which is important when it comes to knowing which apps to remove.

Plugin version

Because there are multiple versions of Studio available, the plugin version must be different for each Version of Studio otherwise we cannot determine which one to use.  This applies to the version numbering before the Studio version in brackets which is simply text added when you submit the plugin to the AppStore.  So in the AppStore the user sees something like this when downloading their apps.

An Incorrect Versioning as both are 2.0.0.0

Correct Versioning

The Studio version name in brackets helps the user to identify the version they want when downloading from the AppStore manually.  The plugin manifest should only contain the semantic versioning convention described below.:

Version Number ( Studio Version) 

No extra special characters should be added in the App Record.  The version number itself should follow a semantic versioning specification as described below:

  • MAJOR version when you make incompatible API changes,
  • MINOR version when you add functionality in a backwards-compatible manner,
  • PATCH version when you make backwards-compatible bug fixes, and
  • INTERNAL version as the builds are released to testing

This means the following would be unnacceptable for example:

1.0
2.4.1

They should be:

1.0.0.0
2.4.1.0

This may not be the convention used by everyone but in order to ensure the best possible experience for users this is the convention to be followed.  It will mean that users will be notified correctly when there is an update available to a plugin that is currently being used in Studio, for example:

Related
Recommended