问题描述
目前正在使用传统的部署方式，每隔几周发布一个版本。他们依赖于语义化版本控制（Semantic Versioning），这在过去的工作中表现良好。然而，他们现在希望通过Jenkins Pipelines等方式更快地发布版本，但不确定最佳的版本控制策略是什么。不使用版本号（只使用快照）似乎是倒退，而频繁创建新版本又会增加很多工作量。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
根据回答1的建议，你可能面临一个X/Y问题。版本控制确实很重要，但似乎你更需要解决问题的根源，即需要按正确的顺序发布软件。你可能还需要同时发布所有的组件，并且整个系统的停机时间很长。
尝试达到以下状态，即能够以任意顺序发布每个组件的新版本：
1. 使用某种形式的依赖注入（Dependency Injection），这是一个大词，但可以是相当简单的，具体取决于你的软件如何工作。
2. 你需要能够在服务器上同时拥有多个版本的每个组件，并且能够在它们之间轻松切换。这种“切换”应该在组件的“用户”一侧进行，而不是在组件本身进行，如果可能的话。
3. 在可以的情况下，还可以同时运行多个实例（对于数据管理等内容，如数据库等，这是受限制的）。
我无法告诉你如何做到这一点，也无法告诉你这有多容易，因为我不了解你的架构或技术限制。但这应该给你一个大致的路线图。
当你实现了这种能力（至少在概念上），你将能够更频繁地发布较小的部分，并且更独立一些。而且，回答你实际问题的是，坚持使用语义化版本控制（SemVer）是一个不错的选择。
方案2
回答2提到了他们使用Jenkinsfile从POM文件中获取版本号（使用语义化版本控制），然后去除快照后缀。然后他们进行Docker构建，并使用该版本号为镜像打标签，最后将其部署到Kubernetes集群。
你可以根据这个思路，在你的Jenkinsfile中创建一个新的阶段，将Maven构建生成的构件上传到Amazon S3或其他云存储中。这样你就可以同时进行Docker容器和构件的发布。
方案3
回答3提到了根据你的需求，版本可以是面向客户的产品版本（版本8.1.2包含这些功能和错误修复），也可以只是用于标识代码在哪里部署的版本。
如果只是用于标识部署的版本，你可以使用提交ID，并使用Jenkins构建号为提交打标签。然而，如果你丢失了Jenkins构建历史记录，这可能会有些混乱，因此最好使用由k8等容器平台管理的某种形式的配置管理数据库（CMDB）。
请注意，以上解决方案仅供参考，具体实施需要根据你的具体情况进行调整。
以上是关于Maven在持续交付或部署中的版本控制策略的解决方案。希望对你有所帮助！