Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate [and fix?] plugin version checking #61087

Closed
joshdover opened this issue Mar 24, 2020 · 5 comments
Closed

Investigate [and fix?] plugin version checking #61087

joshdover opened this issue Mar 24, 2020 · 5 comments
Labels
bug Fixes for quality problems that affect the customer experience Feature:New Platform Feature:Plugins Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc

Comments

@joshdover
Copy link
Contributor

@cjcenizal noticed that many 1st party new platform plugins specify "8.0.0" as their version, even in the 7.x branch.

This points to the possibility that we're not doing any version checks on Platform plugins which is a problem for 3rd party plugins.

We should investigate what version checking we are doing, if there is none, add version checking that mirror what we do in legacy, and finally, update all 1st party plugins to work correctly with the new version checking.

@joshdover joshdover added bug Fixes for quality problems that affect the customer experience Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Feature:New Platform labels Mar 24, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-platform (Team:Platform)

@cjcenizal
Copy link
Contributor

cjcenizal commented Mar 24, 2020

Is there ever a scenario in which version-checking first-party plugins can catch a problem? If not, then perhaps we can allow Kibana maintainers to leave the version field out, and add something to our tooling to handle this intelligently (e.g. automatically generate it from the package.json or simply ignore it).

The reason I suggest this is that it just seems like a hassle for a first-party maintainer to maintain versions (e.g. bumping them) if there's no practical benefit.

@mshustov
Copy link
Contributor

+1 to remove this requirement for first-party plugins. We need to finish work started in #34660

@stacey-gammon
Copy link
Contributor

So, if I'm following correctly, this is how it works today:

version - A required field that is the version of your plugin. If kibanaVersion is specified, this field is ignored. If kibanaVersion is not specified, this has to match the version of Kibana or ci will fail.

kibanaVersion - An optional field that specified the version of Kibana this plugin works against. If you set this to kibana instead of an actual version number, then this field and the version field will be ignored. If you leave this field blank, ci checks will require version to be the current version of Kibana.

And how we want it to work:

version - An optional field that is the version of your plugin.

kibanaVersion - An optional field that specified the version of Kibana this plugin works against.

So, am I right in thinking that the goal is to have plugins put whatever they want inside version and not require it match the Kibana version? The plan is to stop falling back to verifying version if kibanaVersion is not defined?

@pgayvallet
Copy link
Contributor

With the new plugin manifest format, internal plugins no longer have a version field, so I'll go ahead and close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Fixes for quality problems that affect the customer experience Feature:New Platform Feature:Plugins Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Projects
None yet
Development

No branches or pull requests

7 participants