[PROPOSAL] Vary build numbers for every build

[dblock]

Is your feature request related to a problem? Please describe

Currently there's no way to distinguish between two builds of OpenSearch or OpenSearch Dashboards during development by looking at their version number, nor is there a way to introduce a new build when the build changes, but the semantics don't (e.g. as a result of #1130). This makes it difficult to release a new version where binaries are identical but the way we package them together, or the container itself, have changed.

Describe the solution you'd like

Introduce a build number. This number can be, for example, date/time-based (e.g. 202201131018), a random serial number, or a sequential number from the build system. The complete version number would be 1.2.4+202201131018 or 1.2.4.202201131018 if we wanted to replace the last digit with this number. Every time anything is rebuilt, it gets a new build number, without affecting the major/minor/patch parts of it.

[jcgraybill]

Policy / procedure question related to this: is it okay for the current build number to be different for various distribution artifacts at any point in time? Or should there be an expectation that they all match. Now that I type it out, I think that as an administrator I would prefer the former: I don't want to be prompted to update my docker image because an update to the windows installer was released. But if the build numbers vary, will users be concerned that anything they're running with a less-than-highest build number isn't 'current'?

[dblock]

Policy / procedure question related to this: is it okay for the current build number to be different for various distribution artifacts at any point in time? Or should there be an expectation that they all match. Now that I type it out, I think that as an administrator I would prefer the former: I don't want to be prompted to update my docker image because an update to the windows installer was released. But if the build numbers vary, will users be concerned that anything they're running with a less-than-highest build number isn't 'current'?

Haven't we already done this once with 1.0.1 that didn't release a new OpenSearch-min (remained at 1.0.0)? In this issue we're just generalizing this slightly, but whichever way we cut it, if we released distribution 1.2.3.A, then distribution 1.2.3.B is effectively a new release.

[stockholmux]

Two things:

1. SemVer states that build metadata can only be separated by +, so 1.2.4.202201131018 is not possible under the SemVer Spec.
2. In the case of sequential or date-based identifiers, we should be careful not to treat this as a version precedence factor SemVer spec item 10 states that two version with different build metadata have the same version precedence. We shouldn't say 1.2.4+000002 is newer release than 1.2.4+000001.

[dlvenable]

@stockholmux ,

Regarding the +: Docker tags do not support +. So if we choose to create per-build tags in Docker, we'd need to use - or .. e.g. docker pull 1.2.4-202201131018.

Also, SemVer is focused on solving the issue of dependency resolution. When it comes to precedence, the OpenSearch maintainers will perform this resolution. It happens via both:

• Updating the artifacts URLs to download the latest build (e.g. https://artifacts.opensearch.org/releases/bundle/opensearch/1.2.4/opensearch-1.2.4-linux-x64.tar.gz downloads build 1.2.4+000002)
• The Docker tag will be moved to new images and we produce new Docker builds. (e.g. 1.2.4 is tagged on the 1.2.4-000002 image)

By the way, I created a different proposal which may have some impact on this particular discussion in #1621.

[bbarani]

@zelinh @peterzhuamazon Can you please update this issue with the current status?

[bbarani]

@zelinh @peterzhuamazon @prudhvigodithi Can you please update this issue with the current status?

[peterzhuamazon]

We have build number after docker tags right now.
We also have build number separate each tar build.
This can be closed for now.