dubbo多分支api依赖版本管理问题

[cnhaicao]

按官方推荐作法，在服务提供方和服务消费方间抽取公共api工程，服务消费方和服务提供方均依赖此api工程，在使用基于dubbo的微服务架构时，不可避免出现了服务互相调用的问题，会出现工程依赖于多个api工程。我们使用jenkins对所有api使用poll scm检测代码发生变更时将api自动打包到内网nexus私服。
使所有服务提供方及消费方均能顺便依赖这些api工程，当团队协作时，不可避免需要拉多个分支进行并行开发。此时api版本的依赖管理如何作？
假设有分支dev及rel　两个分支的api均可能被修改，此时如果dev及rel分支的api版本号是不是应该区分开，两个分支的api设置不同的版本号吗，然后dev/rel均设置poll scm自动打包nexus,这样的话在代码合并的时侯不可避免带来版本号手工维护问题。请问有其它更好的方法吗？

[kimmking]

hi, cnhaicao,
You mentions a very important question, dubbo need some principals like "best practice" to describe how to use dubbo to achieve MicroServices Architecture.It's a big issue.

Here I share my experience:

• Different branch with different version, such as branchA with version 3.1.2-branchA-snapshot,when branch merged back to master, use master version 3.1.2-release
• Aggregate different api group in different sub projects, then checkout your own api codes, and ref others in pom files.

[ralf0131]

Hi, welcome!

Would you please update the title and description using English? Dubbo is a global community and we would like the issue to be reviewed by people all over the world.

Questions like this are expected to be asked in the mailing list, you can subscribe and ask there.

[cnhaicao]

Dubbo multi-branch api dependent version management issues

According to the official recommendation, the public api project is extracted between the service provider and the service consumer. Both the service consumer and the service provider rely on this api project. When the dubbo-based microservice architecture is used, services are inevitably invoked. The problem that arises is that engineering depends on multiple api projects. We use jenkins to use all the api poll scm detection code changes when the API is automatically packaged to the internal network nexus PW.
All service providers and consumers can rely on these api projects. When teams work together, it is inevitable to pull multiple branches for parallel development. At this point how to do API version dependency management?
Assuming that there are branch api and rel two branches of the api may be modified, this time if the dev and rel branch api version number should not be distinguished, two branch api set a different version number, then dev / rel are Setting the poll scm to auto-negotiate nexus will inevitably lead to manual maintenance of the version number when the code is merged. Is there any other better way?

[cvictory]

It is usage question.

[lovepoem]

Now I think the api can has multi-version. And the service also can have multi-version configured in dubbo:service. e,g.<dubbo:service version="1.1"/>