What is our release cadence

Going forward, we will try encouraging a time based “release train” model with a process that is similar to, but slightly modified, the Apache way of releasing (e.g., Lucene’s release process). This means we strive to have regularly scheduled and loosely planned releases which provides a sense of “predictability” for our customer base. To minimize merge conflicts, and to keep the team in sync, this approach requires “feature freezes” selected by a volunteer Release Manager (RM) indicating the cut-off time a feature Pull Request (PR) is opened and ready to go for review and inclusion in the release. If the feature is not ready, then the train leaves without you and you’ll have to catch the next one. Here is a general outline of the process for a major / minor release:

1. A committer volunteers to be a release manager (or an email is sent requesting a volunteer) and initiates the process by sending an email to the committer list of intent to release the next version (to facilitate discussion and feedback)
2. The RM then proposes a “feature freeze” date (and intent to cut the branch).
   1. initial email also requests all committers begin marking “blocker” issues preventing a successful release
3. 24 hours prior to feature freeze (cutting the branch):
   1. RM sends a “final notice“ email and request to ensure all blockers are identified (some may be fixed by then).
4. On day of feature freeze:
   1. RM sends a “feature freeze” notice email that the branching is underway and no more PRs should be merged.
   2. RM branches from the .x branch into a new .m+1 branch. (.x is now the next minor)
   3. RM sends a “branching complete” email that the branch has been cut and a reminder of the release date requesting all blockers be cleared in time of the release
5. 24 Hours prior to release:
   1. RM sends a “final notice” for blockers email; also requesting a “speak now or forever hold your peace” on critical blockers. If something is holding up the release a postponed release may occur.
6. On Day of Release:
   1. RM tags the branch with the release version
   2. RM begins building and signing artifacts
   3. RM stages artifacts to maven repo
   4. an email is sent once artifacts are published requesting a quorum vote which includes committers run smoke tests on the staged artifacts;
   5. RM sums votes
   6. RM publishes tested artifacts

What model of versioning will be used?

Starting with our new Forks, we will start using semantic versioning based on Apache’s model.

From Apache’s versioning doc :

A release number is comprised of 3 components: the major release number, the minor release number, and an optional point release number. Here is a sample release number:
2.0.4
and it can be broken into three parts:

* major release: 2
* minor release: 0
* point release: 4

The next release of this component would increment the appropriate part of the release number, depending on the type of release (major, minor, or point). For example, a subsequent minor release would be version 2.1, or a subsequent major release would be 3.0.
Note that release numbers are composed of three integers, not three digits. Hence if the current release is 3.9.4, the next minor release is 3.10.0.

How will OpenSearch and OpenSearch-Dashboards versions be related to each other?

NotKibana and NotElasticsearch will release major version together. They will NOT synchronize minor release — whenever the team feels they’re ready to release a minor version or patch (modulo the schedule above), they should release.

What we guarantee is that any major release of NotKibana is compatible with the same major release of NotElasticserach. For example: 3.2.1 of NotKibana will work with 3.0.4 of NotElasticsearch, but 2.3.1 of NotKibana is not guaranteed to work with 3.0.4 of NotElasticsearch

Breaking Changes and Backwards Compatibility

We will not release any breaking changes except in major releases.

How will plug-in versioning work?

All Plug-ins for NotKibana and NotElasticsearch should use the same style of Apache versioning. However, going forward we should plan for plug-ins to be truly standalone pieces of software that can be released separately from notKibana or NotElasticsearch within a major version. We will therefore not enforce the same semantic versioning of guaranteed compatibility within major versions as we do with NotKibana and NotElasticsearch. Each plug-in team is free to create / maintain a compatibility matrix if it makes sense for that plug-in team.

However, practically for the plug-ins that ODFE owns, we may choose to release on the same cadence as notKibana until we are at a state that they can practically release on their own.

We will also consider making the plugin incubation process as easy as possible for the community. For example, we will explore ways of adding gradle or npm tasks that automatically generate a boilerplate plugin project (e.g., ./gradlew newPlugin myNotESPlugin) that set the default starting version as 0.0.0 and uses the same compatibility version of NotES or NotKibana as the one being used to generate the plugin.