Hi,
The problem is fixed. I added the version information of the 2 libraries in
manifest and removed the code.
Please check
https://github.com/apache/incubator-servicecomb-service-center/pull/372
On Fri, Jun 8, 2018 at 10:58 AM, Sure wrote:
> we do not change the code in go-ecosystem package
we do not change the code in go-ecosystem package and we can remove these files
from project
Just make sure the same version of this package compiled with etcd components
when make the release.
-- --
??: "willem.jiang";
:
Congratulations!
2018-06-08 9:57 GMT+08:00 Eric Lee :
> Congratulations!
>
> 2018-06-08 9:39 GMT+08:00 Kirin Wang :
>
> > Congratulations!
> >
> > Zen Lin 于2018年6月8日周五 上午9:38写道：
> >
> > > Congratulations to Zheng Yangyong.
> > >
> > > Best Regards,
> > > ---
> > > Zen Lin
> > >
Congratulations!
2018-06-08 9:39 GMT+08:00 Kirin Wang :
> Congratulations!
>
> Zen Lin 于2018年6月8日周五 上午9:38写道：
>
> > Congratulations to Zheng Yangyong.
> >
> > Best Regards,
> > ---
> > Zen Lin
> > zenlintechnofr...@gmail.com
> > Focused on Micro Service and Apache ServiceComb
> >
> >
Congratulations!
Zen Lin 于2018年6月8日周五 上午9:38写道：
> Congratulations to Zheng Yangyong.
>
> Best Regards,
> ---
> Zen Lin
> zenlintechnofr...@gmail.com
> Focused on Micro Service and Apache ServiceComb
>
> 2018-06-08 9:34 GMT+08:00 Willem Jiang :
>
> > Please join me and the rest of the
Congratulations to Zheng Yangyong.
Best Regards,
---
Zen Lin
zenlintechnofr...@gmail.com
Focused on Micro Service and Apache ServiceComb
2018-06-08 9:34 GMT+08:00 Willem Jiang :
> Please join me and the rest of the ServiceComb PPMC members in welcoming
> our
> new ServiceComb committer: Zheng
Please join me and the rest of the ServiceComb PPMC members in welcoming our
new ServiceComb committer: Zheng Yangyong (郑扬勇).
Yangyong is active ServiceComb contributor since July 2017. He has
contributed to the project in different ways (website, email, examples, and
much more)
and we look
+1 to Yang Bo's suggestion,
Forked to your own github organization, then used in ServiceCenter as a
vendor referenced to your forked brench.
The problem introduced by this approach is that the cloner needs to
maintain its own branch, but if you modified the libraries, no way to
escape maintaining
I think it is better to decoupled package it if we want to add something
enhanced, but not just only modified it and then keep in the third-party.
Anyway , third-party is not a regular and recommended way to using golang
libraries.
Best Regards,
---
Zen Lin
zenlintechnofr...@gmail.com
Focused
If we do have modified those libraries, it's better we make a fork of them
on github and the use the forks.
It's still better that we use them directly as is to ease later upgrade and
do the work in our code through wrappers.
On Thu, Jun 7, 2018 at 11:32 AM, Willem Jiang
wrote:
> If we changed
10 matches
Mail list logo
