Versioning Plugins
editVersioning Plugins
editLogstash core and its plugins have separate product development lifecycles. Hence the versioning and release strategy for the core and plugins do not have to be aligned. In fact, this was one of our goals during the great separation of plugins work in Logstash 1.5.
At times, there will be changes in core API in Logstash, which will require mass update of plugins to reflect the changes in core. However, this does not happen frequently.
For plugins, we would like to adhere to a versioning and release strategy that can better inform our users, about any breaking changes to the Logstash configuration formats and functionality.
Plugin releases follows a three-placed numbering scheme X.Y.Z. where X denotes a major release version which may break compatibility with existing configuration or functionality. Y denotes releases which includes features which are backward compatible. Z denotes releases which includes bug fixes and patches.
Changing the version
editVersion can be changed in the Gemspec, which needs to be associated with a changelog entry. Following this, we can publish the gem to RubyGem.org manually. At this point only the core developers can publish a gem.
Labeling
editLabeling is a critical aspect of maintaining plugins. All issues in GitHub should be labeled correctly so it can:
- Provide good feedback to users/developers
- Help prioritize changes
- Be used in release notes
Most labels are self explanatory, but here’s a quick recap of few important labels:
-
bug: Labels an issue as an unintentional defect -
needs details: If a the issue reporter has incomplete details, please ask them for more info and label as needs details. -
missing cla: Contributor License Agreement is missing and patch cannot be accepted without it -
adopt me: Ask for help from the community to take over this issue -
enhancement: New feature, not a bug fix -
needs tests: Patch has no tests, and cannot be accepted without unit/integration tests -
docs: Documentation related issue/PR