ote:>
> > >>>>>>>>
> > >>>>>>>> Just think a bit on this. I agree that generally introducing>
> > >>>>>>>> different versions of same dependencies could be error prone. But
> > >>>>&g
t think a bit on this. I agree that generally introducing>
> > >>>>>>>> different versions of same dependencies could be error prone.
> But I think>
> > >>>>>>>> the case here should not lead to issue:>
> > >
think>
> >>>>>>>> the case here should not lead to issue:>
> >>>>>>>>>
> >>>>>>>> 1. These two sub-modules spark-2 and spark-3 are isolated, they're>
> >>>>>>>> not depen
t;>>>>>> Best regards,
>>>>>>>> Saisai
>>>>>>>>
>>>>>>>> Saisai Shao 于2020年3月4日周三 上午10:01写道：
>>>>>>>>
>>>>>>>>> Thanks Matt,
>>>>>>>>&g
hing is the only choice, then we would potentially have two
>>>>>>>> *master* branches until spark-3 is vastly adopted. That will somehow
>>>>>>>> increase the maintenance burden and lead to inconsistency. IMO I'm OK
>>>>>>&
IMO I'm OK
>>>>>>> with
>>>>>>> the branching way, just think that we should have a clear way to keep
>>>>>>> tracking of two branches.
>>>>>>>
>>>>>>> Best,
>>>>>>>
t;>> Matt Cheah 于2020年3月4日周三 上午9:50写道：
>>>>>>
>>>>>>> I think it’s generally dangerous and error-prone to try to support
>>>>>>> two versions of the same library in the same build, in the same
>>>>>>> published
>&g
I would think that branching would be the best way to build and publish
> against multiple versions of a dependency.
>
>
>
> -Matt Cheah
>
>
>
> From: Saisai Shao mailto:sai.sai.s...@gmail.com>>
> Reply-To: "dev@iceberg.apache.org <mailto:dev@i
>>>> I think it’s generally dangerous and error-prone to try to support
>>>>>> two versions of the same library in the same build, in the same published
>>>>>> artifacts. This is the stance that Baseline
>>>>>> <https://github.com/palantir/gradl
;
>>>>> takes. Gradle Consistent Versions is specifically opinionated towards
>>>>> building against one version of a library across all modules in the build.
>>>>>
>>>>>
>>>>>
>>>>> I would think that branchi
lly opinionated towards
>>>> building against one version of a library across all modules in the build.
>>>>
>>>>
>>>>
>>>> I would think that branching would be the best way to build and publish
>>>> against multiple versi
ry across all modules in the build.
>>>
>>>
>>>
>>> I would think that branching would be the best way to build and publish
>>> against multiple versions of a dependency.
>>>
>>>
>>>
>>> -Matt Cheah
>>>
>>
;
>> *From: *Saisai Shao
>> *Reply-To: *"dev@iceberg.apache.org"
>> *Date: *Tuesday, March 3, 2020 at 5:45 PM
>> *To: *Iceberg Dev List
>> *Cc: *Ryan Blue
>> *Subject: *Re: [Discuss] Merge spark-3 branch into master
>>
>>
>>
>> I did
gt;
> I would think that branching would be the best way to build and publish
> against multiple versions of a dependency.
>
>
>
> -Matt Cheah
>
>
>
> *From: *Saisai Shao
> *Reply-To: *"dev@iceberg.apache.org"
> *Date: *Tuesday, March 3, 2020 at
-Matt Cheah
From: Saisai Shao
Reply-To: "dev@iceberg.apache.org"
Date: Tuesday, March 3, 2020 at 5:45 PM
To: Iceberg Dev List
Cc: Ryan Blue
Subject: Re: [Discuss] Merge spark-3 branch into master
I didn't realized that Gradle cannot support two different versions in one
build. I
I didn't realized that Gradle cannot support two different versions in one
build. I think I did such things for Livy to build scala 2.10 and 2.11 jars
simultaneously with Maven. I'm not so familiar with Gradle thing, I can
take a shot to see if there's some hacky ways to make it work.
Besides, are
+1 for a 0.8.0 release with Spark 2.4 and then move on for Spark 3.0 when
it's ready.
On Tue, 3 Mar 2020 at 16:32, Ryan Blue wrote:
> Thanks for bringing this up, Saisai. I tried to do this a couple of months
> ago, but ran into a problem with dependency locks. I couldn't get two
> different ver
t;dev@iceberg.apache.org" ,
"rb...@netflix.com"
Date: Tuesday, March 3, 2020 at 8:32 AM
To: Iceberg Dev List
Subject: Re: [Discuss] Merge spark-3 branch into master
Thanks for bringing this up, Saisai. I tried to do this a couple of months ago,
but ran into a problem with dependency locks
Thanks for bringing this up, Saisai. I tried to do this a couple of months
ago, but ran into a problem with dependency locks. I couldn't get two
different versions of Spark packages in the build with baseline, but maybe
I was missing something. If you can get it working, I think it's a great
idea t
Hi team,
I was thinking of merging spark-3 branch into master, also per the
discussion before we could make spark-2 and spark-3 coexisted into 2
different sub-modules. With this, one build could generate both spark-2 and
spark-3 runtime jars, user could pick either at preference.
One concern is t
20 matches
Mail list logo
