I shall update the README file and website later.
> 在 2019年9月23日，17:33，Willem Jiang <[email protected]> 写道：
>
> +1, I think it's a good way to go.
> Please add some description in the binary release kit to specify the
> difference between the weex_sdk and weex_sdk_legacy.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Sep 18, 2019 at 3:25 PM Jan Piotrowski <[email protected]> wrote:
>>
>> Exactly, that is the opposite of what your original email said ;)
>>
>>> weex_sdk will be compiled using the gradle-plugin mentioned above, while
>>> weex_sdk_legacy will not.
>>
>> But I understand now and agree with your suggestion.
>>
>> J
>>
>> Am Mi., 18. Sept. 2019 um 04:40 Uhr schrieb York Shen <[email protected]>:
>>>
>>> Nope.
>>>
>>> The class name in source code(.java) will be ‘org.apache.weex’, as this is
>>> the right thing to do, IMO. The apache source code release will be under
>>> ‘org.apache.weex’ as well.
>>> The weex_sdk will be built without the plugin therefore its package name
>>> shall also be 'org.apache.weex'.
>>> The weex_sdk_legacy will be built with the plugin therefore its package
>>> name shall be ‘com.taobao.weex'.
>>> Users can choose whichever the above connivence library they’d like.
>>>
>>>
>>>> 在 2019年9月18日，02:56，Jan Piotrowski <[email protected]> 写道：
>>>>
>>>> Sounds good.
>>>>
>>>>> weex_sdk will be compiled using the gradle-plugin mentioned above, while
>>>>> weex_sdk_legacy will not.
>>>>
>>>> Don't you mean the other one around? The legacy one should be built
>>>> using the plugin, leading to the class names being replaced with the
>>>> old ones.
>>>>
>>>> -J
>>>>
>>>> Am Di., 17. Sept. 2019 um 13:56 Uhr schrieb York Shen
>>>> <[email protected] <mailto:[email protected]>>:
>>>>>
>>>>> Hi, community
>>>>>
>>>>> Due to the restriction of Java language in method overriding [1], the
>>>>> solution I proposed months ago will not provide backwards-compatibility
>>>>> as expected but produce compiling error for users.
>>>>>
>>>>> Therefore, I’d like to proposal a new solution to fix the problem.
>>>>>
>>>>> Package name will be renamed from 'com.taobao.weex' to 'org.apache.weex'
>>>>> in source code and Apache Source Release as the previous plan.
>>>>> Create a custom gradle-plugin which could rename package back to
>>>>> ‘com.taobao.weex’ at compiling time.
>>>>> Publish two build variants (weex_sdk and weex_sdk_legacy) each time
>>>>> building connivence library. weex_sdk will be compiled using the
>>>>> gradle-plugin mentioned above, while weex_sdk_legacy will not.
>>>>> Therefore, classes in weex_sdk will be under ‘org.apache.weex' package,
>>>>> and classes in weex_sdk_legacy will be under ‘com.taobao.weex’.
>>>>> New users of weex should choose weex_sdk and new API, while current users
>>>>> could continue using weex_sdk_legacy which provide the same API behavior
>>>>> as now.
>>>>> Finally, we would stop publishing weex_sdk_legacy sometime later.
>>>>>
>>>>> The community could benefit from the above solution in following aspects:
>>>>> For me, there is much less work to do in current plan than the old one.
>>>>> Less bug to write, less time to use. One or two weeks will be enough.
>>>>> For users, There is a guarantee that the API behavior of weex_sdk_legacy
>>>>> is the same as before because the source code after processing of
>>>>> gradle-plugin is the same as before. The old plan won’t give this
>>>>> guarantee.
>>>>> We make our position very clear by naming the connivence binary to
>>>>> weex_sdk_legacy .
>>>>>
>>>>> [1] "When overriding a method, the signatures (name and argument types)
>>>>> have to be the same after type erasure." Ref
>>>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2
>>>>> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2>
>>>>> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2
>>>>> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2>>
>>>>> for detail.
>>>>>
>>>>> Best Regards,
>>>>> York Shen
>>>>>
>>>>> 申远
>>>>>
>>>>>> 在 2019年7月1日，16:26，Jan Piotrowski <[email protected]
>>>>>> <mailto:[email protected]>> 写道：
>>>>>>
>>>>>> Sounds pretty neat and was pretty much what I was thinking of.
>>>>>>
>>>>>> Th
>>>
