To make it easier to categorize dynamic plugins, this is a proposal to add some standardized keywords, a new supported-versions field to the backstage field, and to encourage use of several standard package.json fields.
For example:
{
"name": "@janus-idp/backstage-plugin-myplugin",
"version": "0.7.2",
"license": "Apache-2.0",
"author": "Red Hat",
"maintainers": ["Plugin Dev Guy <pdg@mycorp.com>"],
"homepage": "https://mycorp.com/pdg-plugins",
"keywords": [
"support:production",
"lifecycle:active",
"groupid:myplugin",
"usage:ci-cd",
"usage:integration",
"feature:rbac-something-details",
"feature:audit-log",
"feature:scaled-deployments",
"restriction:single-instance"
],
"backstage": {
"role": "frontend-plugin",
"supported-versions": "^1.26.4"
}
}-
Under the
backstagefield, add asupported-versionsset to a nodejs-standard version string. For example:
{
"backstage": {
"role": "frontend-plugin",
"supported-versions": "^1.26.4"
}
}In order to achieve machine-readability, we need standardization. Here are the allowed values for the new keywords.
This defines where the plugin is in its support lifecycle, in terms of quality and degree of support. Production (GA) is the highest support level, perhaps via paid subscription or other purchase model.
Below that is Technology Preview (TP), which seeks to eventually stabilize and move to production but is currently not fully supported.
Alpha and beta are for new, unsupported code.
-
Add a keyword item, starting with
support:and then one of 'alpha', 'beta', 'tech-preview', 'production'. For example:
{
"keywords": [
"support:production"
}As plugins are created, evolve, and eventually discarded or abandoned, they will move though a lifecycle. These states might be able to be changed mechanically based on threshholds; for example if the last commit in the plugin’s codebase was 6 months ago, it might be in maintenance mode; if known CVE issues are reported and not fixed, it might be moved to 'deprecated' or 'inactive' to warn consumers not to use it. Deprecated can also be used to identify that a new plugin replaces this old one.
-
Add a keyword item, starting with
lifecycle:and then one of: 'active', 'maintenance', 'deprecated', 'inactive', 'retired'. For example:
{
"keywords": [
"lifecycle:active"
}-
Add a keyword item, starting with
groupid:, then a freeform string to group multiple plugins under the same workspace/functional group, eg., github, ocm, myfeatureset. For example:
{
"keywords": [
"groupid:myplugin"
}These three keyword prefixes can be used to define how a plugin is intended to be used, what it provides or interacts with, and any restrictions on its use. This information should also appear in the README or plugin documentation, but boiling that longform doc down to a set of keywords will allow better searching/filtering.
-
Add a keyword item, starting with the three prefixes above, then a keyword chosen from a pool of available strings. For example:
{
"keywords": [
"usage:ci-cd",
"usage:search",
"usage:dashboard",
]
}{
"keywords": [
"feature:rbac-aspect1",
"feature:rbac-aspect2",
"feature:audit-log",
"feature:scaled-deployments"
]
}{
"keywords": [
"restriction:single-instance"
"restriction:ocp"
]
}There are other standard fields that should be used, such as license, author, maintainers, homepage, and repository. For example:
{
"license": "Apache-2.0",
"author": "Red Hat",
"maintainers": ["Plugin Dev Guy <pdg@mycorp.com>"],
"homepage": "https://mycorp.com/pdg-plugins",
"repository": {
"type": "git",
"url": "https://github.com/backstage/community-plugins",
"directory": "workspaces/mygroup/plugins/myplugin"
},
}For Community-supported plugins not owned by a specific vendor, the Author field could be set to Community or Backstage Community.
Community support can mean many things, such as the availability of learning resources, the frequency of updates, the quality of documentation, the size and diversity of the user base, and the responsiveness of the developers.