Overview
| Artifact ID: | 6dfc8818efc37f2f8487256c64023938adc4cfd26e3f9e3a85ff9d53d1cd916b |
|---|---|
| Page Name: | version |
| Date: | 2018-07-04 01:39:18 |
| Original User: | mario |
| Mimetype: | text/x-markdown |
| Parent: | b9b61a672790afe693aacc9465c3669cf02ebe1429b32128524e752c38f6edd3 (diff) |
| Next | e84767fa890cb626777753c9c00d8597072076d53f30e66d8f1fdcb6b188359f |
Content
# version:
Each plugin may carry its own version number:
# version: 0.5
Which makes sense as features progress independly of the main application. It's the whole point of plugin systems to encapsulate functionality.
Often it suffices to use MINOR.MAJOR schemes.
For larger plugins the more common SEMVER versioning might make sense still.
Patch versions etc. however shouldn't be part of the
version:field.
Instead one can use state: or support: to expand on the current code quality/completion.