[BUG][2.5.10] Implementation-Version is incorrect

[nobodyiam]

The manifest info of the newly released 2.5.10 is incorrect, which causes com.alibaba.dubbo.common.Version#getVersion() returns the wrong version - 2.0.1.

The following is the manifest of 2.5.10:

Manifest-Version: 1.0
Implementation-Vendor: The Dubbo Project
Implementation-Title: Dubbo
Implementation-Version: 2.0.1
Implementation-Vendor-Id: com.alibaba
Built-By: ken.lj
Build-Jdk: 1.7.0_80
Specification-Vendor: The Dubbo Project
Specification-Title: Dubbo
Created-By: Apache Maven 3.1.1
Specification-Version: 2.0.0
Archiver-Version: Plexus Archiver

Here is the manifest of 2.5.8, which is correct:

Manifest-Version: 1.0
Implementation-Vendor: Alibaba
Implementation-Title: Dubbo
Implementation-Version: 2.5.8
Implementation-Vendor-Id: com.alibaba
Built-By: ken.lj
Build-Jdk: 1.6.0_32
Specification-Vendor: Alibaba
Specification-Title: Dubbo
Created-By: Apache Maven 3.1.1
Specification-Version: 2.5.8
Archiver-Version: Plexus Archiver

[chickenlj]

This has been changed since 2.5.9, does this change has some side effects on your project?

…

On 14 Mar 2018, at 11:25 AM, Jason Song ***@***.***> wrote: The manifest info of the newly released 2.5.10 is incorrect, which causes com.alibaba.dubbo.common.Version#getVersion() returns the wrong version - 2.0.1. The following is the manifest of 2.5.10: Manifest-Version: 1.0 Implementation-Vendor: The Dubbo Project Implementation-Title: Dubbo Implementation-Version: 2.0.1 Implementation-Vendor-Id: com.alibaba Built-By: ken.lj Build-Jdk: 1.7.0_80 Specification-Vendor: The Dubbo Project Specification-Title: Dubbo Created-By: Apache Maven 3.1.1 Specification-Version: 2.0.0 Archiver-Version: Plexus Archiver Here is the manifest of 2.5.8, which is correct: Manifest-Version: 1.0 Implementation-Vendor: Alibaba Implementation-Title: Dubbo Implementation-Version: 2.5.8 Implementation-Vendor-Id: com.alibaba Built-By: ken.lj Build-Jdk: 1.6.0_32 Specification-Vendor: Alibaba Specification-Title: Dubbo Created-By: Apache Maven 3.1.1 Specification-Version: 2.5.8 Archiver-Version: Plexus Archiver — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1466>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARQlibiLp75nQ36yl5VeDV9uhIqZOwqVks5teI2OgaJpZM4Spx8r>.

[nobodyiam]

We have integrated dubbo with our tracing system, which will include dubbo version in each rpc call event.

The version information is one of the key diagnosis information when some service meets something wrong.

So yes, this change does have some side effects. Not on my project but on many services using our sdk.

[chickenlj]

Hi Jun, We have integrated dubbo with our tracing system, which will include dubbo version in each rpc call event. The version information is one of the key diagnosis information when some service meets something wrong. So yes, this change does have some side effects. Not on my project but on many services using our sdk. Thanks! Jason

…

On 14/03/2018, 14:27, "Jun Liu" ***@***.***> wrote: This has been changed since 2.5.9, does this change has some side effects on your project? > On 14 Mar 2018, at 11:25 AM, Jason Song ***@***.***> wrote: > > The manifest info of the newly released 2.5.10 is incorrect, which causes com.alibaba.dubbo.common.Version#getVersion() returns the wrong version - 2.0.1. > > The following is the manifest of 2.5.10: > > Manifest-Version: 1.0 > Implementation-Vendor: The Dubbo Project > Implementation-Title: Dubbo > Implementation-Version: 2.0.1 > Implementation-Vendor-Id: com.alibaba > Built-By: ken.lj > Build-Jdk: 1.7.0_80 > Specification-Vendor: The Dubbo Project > Specification-Title: Dubbo > Created-By: Apache Maven 3.1.1 > Specification-Version: 2.0.0 > Archiver-Version: Plexus Archiver > Here is the manifest of 2.5.8, which is correct: > > Manifest-Version: 1.0 > Implementation-Vendor: Alibaba > Implementation-Title: Dubbo > Implementation-Version: 2.5.8 > Implementation-Vendor-Id: com.alibaba > Built-By: ken.lj > Build-Jdk: 1.6.0_32 > Specification-Vendor: Alibaba > Specification-Title: Dubbo > Created-By: Apache Maven 3.1.1 > Specification-Version: 2.5.8 > Archiver-Version: Plexus Archiver > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub <#1466>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARQlibiLp75nQ36yl5VeDV9uhIqZOwqVks5teI2OgaJpZM4Spx8r>. >

[beiwei30]

Jason, Pls. file an issue on github. Thanks, -Ian.

…

On 14 Mar 2018, at 3:52 PM, ken.lj ***@***.***> wrote: Hi Jun, We have integrated dubbo with our tracing system, which will include dubbo version in each rpc call event. The version information is one of the key diagnosis information when some service meets something wrong. So yes, this change does have some side effects. Not on my project but on many services using our sdk. Thanks! Jason On 14/03/2018, 14:27, "Jun Liu" ***@***.*** ***@***.***>> wrote: >This has been changed since 2.5.9, does this change has some side effects on your project? > >> On 14 Mar 2018, at 11:25 AM, Jason Song ***@***.*** ***@***.***>> wrote: >> >> The manifest info of the newly released 2.5.10 is incorrect, which causes com.alibaba.dubbo.common.Version#getVersion() returns the wrong version - 2.0.1. >> >> The following is the manifest of 2.5.10: >> >> Manifest-Version: 1.0 >> Implementation-Vendor: The Dubbo Project >> Implementation-Title: Dubbo >> Implementation-Version: 2.0.1 >> Implementation-Vendor-Id: com.alibaba >> Built-By: ken.lj >> Build-Jdk: 1.7.0_80 >> Specification-Vendor: The Dubbo Project >> Specification-Title: Dubbo >> Created-By: Apache Maven 3.1.1 >> Specification-Version: 2.0.0 >> Archiver-Version: Plexus Archiver >> Here is the manifest of 2.5.8, which is correct: >> >> Manifest-Version: 1.0 >> Implementation-Vendor: Alibaba >> Implementation-Title: Dubbo >> Implementation-Version: 2.5.8 >> Implementation-Vendor-Id: com.alibaba >> Built-By: ken.lj >> Build-Jdk: 1.6.0_32 >> Specification-Vendor: Alibaba >> Specification-Title: Dubbo >> Created-By: Apache Maven 3.1.1 >> Specification-Version: 2.5.8 >> Archiver-Version: Plexus Archiver >> — >> You are receiving this because you are subscribed to this thread. >> Reply to this email directly, view it on GitHub <#1466 <#1466>>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARQlibiLp75nQ36yl5VeDV9uhIqZOwqVks5teI2OgaJpZM4Spx8r <https://github.com/notifications/unsubscribe-auth/ARQlibiLp75nQ36yl5VeDV9uhIqZOwqVks5teI2OgaJpZM4Spx8r>>. >> > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1466 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARybXAD_T7khgeHmXg8deL_vCKoj0VSeks5teMxAgaJpZM4Spx8r>.

[kimmking]

i think 2.5.10 is better

[chickenlj]

Sorry for bothering you. I have checked the design purpose and implementation code before made this change. I believe the `version` here means the implementation version of the RPC Protocol, also the Protocol-Specific-Version means the specification of RPC Protocol. If i understand the `version` in a right way, don’t think it should be changed for every release(or at least don’t have to be the same with the jar version). I know that there maybe some compatible problems if someone relies on this “version number the same with the jar version” rule, but this change should not cause any critical problems on remote procedures. I tend to do this when i have to do a compatible upgrade for RPC protocols, check this PR(#1442 (comment) <#1442 (comment)>, not completely finished yet). I think it would be better for us to keep a stable version number instead of change every release. Only my opinion. And I believe when we follow the apache way by using the dev mailing list - dev@dubbo.apache.org, we can avoid any changes before they are fully discussed.

…

On 14 Mar 2018, at 3:51 PM, ss宋顺 ***@***.***> wrote: Hi Jun, We have integrated dubbo with our tracing system, which will include dubbo version in each rpc call event. The version information is one of the key diagnosis information when some service meets something wrong. So yes, this change does have some side effects. Not on my project but on many services using our sdk. Thanks! Jason On 14/03/2018, 14:27, "Jun Liu" ***@***.***> wrote: > This has been changed since 2.5.9, does this change has some side effects on your project? > >> On 14 Mar 2018, at 11:25 AM, Jason Song ***@***.***> wrote: >> >> The manifest info of the newly released 2.5.10 is incorrect, which causes com.alibaba.dubbo.common.Version#getVersion() returns the wrong version - 2.0.1. >> >> The following is the manifest of 2.5.10: >> >> Manifest-Version: 1.0 >> Implementation-Vendor: The Dubbo Project >> Implementation-Title: Dubbo >> Implementation-Version: 2.0.1 >> Implementation-Vendor-Id: com.alibaba >> Built-By: ken.lj >> Build-Jdk: 1.7.0_80 >> Specification-Vendor: The Dubbo Project >> Specification-Title: Dubbo >> Created-By: Apache Maven 3.1.1 >> Specification-Version: 2.0.0 >> Archiver-Version: Plexus Archiver >> Here is the manifest of 2.5.8, which is correct: >> >> Manifest-Version: 1.0 >> Implementation-Vendor: Alibaba >> Implementation-Title: Dubbo >> Implementation-Version: 2.5.8 >> Implementation-Vendor-Id: com.alibaba >> Built-By: ken.lj >> Build-Jdk: 1.6.0_32 >> Specification-Vendor: Alibaba >> Specification-Title: Dubbo >> Created-By: Apache Maven 3.1.1 >> Specification-Version: 2.5.8 >> Archiver-Version: Plexus Archiver >> — >> You are receiving this because you are subscribed to this thread. >> Reply to this email directly, view it on GitHub <#1466>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARQlibiLp75nQ36yl5VeDV9uhIqZOwqVks5teI2OgaJpZM4Spx8r>. >> >

[nobodyiam]

Thanks for the clarification, I'm OK with this for now.

However, I'm not sure whethere it's a good idea to bind RPC protocol Version to the Specification-Version in a Jar Manifest file.

In my opinion, they are 2 different concepts. For example, one jar file could provide several different rpc protocols, in that case, we won't be able to use the Specification-Version in one Jar Manifest file to represent multiple RPC protocol Versions.

[chickenlj]

However, I'm not sure whethere it's a good idea to bind RPC protocol Version to the Specification-Version in a Jar Manifest file. In my opinion, they are 2 different concepts. For example, one jar file could provide several different rpc protocols, in that case, we won't be able to use the Specification-Version in one Jar Manifest file to represent multiple RPC protocol Versions

Agree with you. Maybe we should figure out a new way for identifying RPC version, separate RPC protocol Version from the Manifest specification/implementation version.

…

On 18 Mar 2018, at 4:00 PM, Jason Song ***@***.***> wrote: Thanks for the clarification, I'm OK with this for now. However, I'm not sure whethere it's a good idea to bind RPC protocol Version to the Specification-Version in a Jar Manifest file. In my opinion, they are 2 different concepts. For example, one jar file could provide several different rpc protocols, in that case, we won't be able to use the Specification-Version in one Jar Manifest file to represent multiple RPC protocol Versions. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1466 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARQlicYXRMmaZn87ejbW_mbd1uSCgixNks5tfhQmgaJpZM4Spx8r>.

[lovepoem]

https://github.com/apache/incubator-dubbo/blob/master/dubbo-common/src/main/java/com/alibaba/dubbo/common/Version.java

Version.java read version from MANIFEST.MF or jar name.

Now you debug in classes generated by IDE, no MANIFEST.MF or jar name found

Must we support the IDEA debug environment?

If so，we can refer this Generate a Version.java file in Maven