我们最近开始使用WSO2 API管理器，我们希望对版本处理方面有所了解。默认情况下，版本号是可用的，并且是强制性的。
Q1。我们可以改变这个吗？或者是否必须使用它？
Q2。仅当服务签名发生变化时，版本是否应该更改？即我对服务进行后端更改，这不会导致Web服务中的公开方法发生更改。在这种情况下，我们是否更改版本号？或者只有在方法改变时我们才改变它吗？
Q3。不断更改应用程序的服务URL是不是很麻烦？特别是如果服务用于移动应用程序？
希望您对当前实施中遵循的此方法和任何方法的见解非常受欢迎。谢谢！
答案 0 :(得分：0)
答案1a。版本控制方案的格式不是强制性的，但是WSO2建议使用＆＃34; version.major.minor＆＃34;做法。在初始发布期间，可能不需要甚至不需要API版本控制，但是当需要撤销错误的api，或者升级免费增值选项或需要提供关键更新时，可能会节省一些情况。 。但恕我直言，这是最好的做法，首先。
答案1b。您必须使用某种版本方案来区分API的版本。
答案2.您如何参与版本控制实施实际上是基于对DevOps团队最有效的方法。如果遵循version.major.minor方案，您在表达格式更改方面具有很大的灵活性。查看维基百科的页面[1]，有一些非常有用的升级示例，您的用户一定会感谢您。由于每个团队在偏好和实践方面都存在差异，因此我很难在不了解您的团队的版本化文化的情况下提出版本控制方案。不过，我建议首先考虑用户选择;最终用户（应用程序开发人员）的利益最重要的是，他们对版本控制实施不当的挫败感可能是使用和陈旧之间的差异。应用程序开发人员，您的用户，希望版本控制与他们期望的升级和错误修复一样多。我不相信不影响API的服务更改应该从纯粹的功能角度导致API版本更新，但作为应用程序开发人员，如果您更改任何内容，我希望您对其进行版本更改，因为我想要在船上你的完美＆＃34;由于即使从最完美的团队中出现的错误，也可以在我自己的周期和最佳实践中进行更改，因此可以回滚。我建议您在更新不能更改功能的服务时，将其作为次要+ 1更改发布，并将其作为升级选项提供给用户，并允许现有API保持不变（从最终开始）通过不折旧以及不要求重新订阅。但是，当您更改方法或修复错误时，请分别将其作为版本+ 1或主要版本+1推出，并要求重新订阅以确保明确说明更改和建议的入职程序，并设置贬值旧的过时或错误版本的日期。
答案3.在颠倒视角时，我相信您的用户更愿意将API工作视为订阅，端到端，并且他们希望升级以适应任何地方发生的任何和所有更改。该API的服务。如上所述，它既有助于入职，也有助于回滚，也可以作为对最佳实践的专业期望。
最后，管理不安用户和糟糕的版本控制将会非常麻烦。您可能还想设置计划版本更改的计划，以便您的开发人员意识到您的商店中有一个良好的持续改进计划。