Make sure this project follows SemVer

[peternied]

Description

This project has its own versioning pattern, which follows the Major, minor and patch syntax and it is not following SemVer [1] for feature compatibility as public APIs are not backward compatible and major features are removed or without prior deprecation notice.

While it looks like there are similarities to the versioning and branching structure of the OpenSearch this project should have its own release process documented.

Additional Information

• [1] https://semver.org/
• Coming from Add minor and patch release information. .github#227 (comment)

[sumobrian]

This approach is intentional. While Semantic Versioning has its benefits, it provides limited value for a solution designed to be ephemeral. As outlined in the documentation, the recommended strategy is to uninstall and redeploy the solution as needed: https://docs.aws.amazon.com/solutions/latest/migration-assistant-for-amazon-opensearch-service/deploy-the-solution.html.

At this stage, we've chosen to avoid unnecessary processes that could slow down our agility without delivering significant advantages. This is also why we maintain a separate release schedule from OpenSearch core. Our focus remains on staying nimble, only introducing additional structure when it meaningfully supports our progress.

Currently, we have no API boundaries, but we plan to introduce them in the future. When the time comes, we will adopt Semantic Versioning or another versioning scheme that ensures we can guarantee stable contracts between users and developers.

We all understand the value of Semantic Versioning and when it should be applied, but we often overlook challenging whether a process is truly advantageous. This is a case where I want everyone to carefully consider the tradeoffs.

[peternied]

As outlined in the documentation, the recommended strategy is to uninstall and redeploy the solution as needed

While this is an understandable position, the intention of the OpenSearch-Project to follow SemVer is to inform dependencies on how to handle updates from this packages in this project.

By incrementing the major version number on every release this project would still follow SemVer and set expectations with downstream projects. Is there anything standing in the way of making that process change to be in compliance?