Tags to be used for security plugin releases

[vrozov]

Versions of the security plugin were reset to 1.x after move to OpenSearch. It is necessary to agree on the tag naming convention as v.1.x.x.x scheme conflicts with the existing tags for ODFE releases. We can either switch to release-1.x.x.x scheme or use v1.x.x.x-OS scheme. Any other options?

[cliu123]

Adding @peterzhuamazon @dblock to continue the discussion that started in GA release readiness.

[dblock]

I suggest opening a PR proposal into https://github.com/opensearch-project/.github/blob/main/RELEASING.md and discussing it there? Once merged we can call it "agreement". There's some discussion on tags in opensearch-project/.github#13 and I believe 1.0 has been tagged with a certain scheme in mind already, so I would start by matching that closely.

[vrozov]

The existing scheme for OpenSearch 1.0 will not work for the security plugin and I strongly recommend not to use it for other repos as well. The majority of open source projects use either v.x.x.x scheme or release-x.x.x scheme or project-x.x.x scheme.

[dblock]

The issue is that the current scheme (n.n.n.n) makes it difficult if not impossible for GitHub CD pipeline in the security plugin to distinguish a release tag from any other tag. That pipeline today triggers builds on tags starting with v.

[cliu123]

The issue is that the current scheme (n.n.n.n) makes it difficult if not impossible for GitHub CD pipeline in the security plugin to distinguish a release tag from any other tag.

To clarify, currently, security plugin's CD is triggered by tags starting with v . Tags not starting with v don't trigger CD with the configuration that security plugin currently has because they are not considered as release tags. If we decide to remove v from release tags, the format of tags to trigger CD will need to be changed like this (line 6 in cd.yml file), which means all tags will trigger CD workflow.
While almost all the tags that we currently have start with v , which means almost all the tags are considered as release tags, the concern mentioned above on this is that there might be tags that are not release tags at some point in the future, it'd be not easy to distinguish release tags from non-release tags without adding v as prefix in release tags.

[davidlago]

Closing issue as we have settled on a version/tag standard project-wide.