[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Guava versions in Oxygen

Hi Ed

 

Thanks for the answer. Trace Compass requires minimum version 15, but we don’t use any API from later versions nor use APIs of 15 that has been removed in later versions.

So, I’m good to go to move to 21 since Trace Compass will work with either version.

 

Bernd

 

From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Ed Willink
Sent: May-16-17 1:28 AM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: Re: [cross-project-issues-dev] Guava versions in Oxygen

 

Hi

If your project is open to exploitation by other projects or depends on a diveristy og Guava-using projects, IMHO you must tolerate Guava 21 since Guava 21 is the most recent version in Orbit. Also you should tolerate 21 because Mylyn has a precisely 21 bounds. Many other projects are better Eclipse citizens and tolerate a range of versions including at least 15 and 21. I recommend that you just open the upperbound to 21, test with 21, and write private versions of everything you need that 21 deletes and 15 provided. Do not use any post Guava 15 facilities.

    Regards

        Ed Willink

 

On 15/05/2017 20:47, Bernd Hufmann wrote:

Hello

 

I’m not clear which version of Guava to use for our project (Trace Compass).

I planned to switch to Guava v21 for M7 this Wednesday.

 

I will do so unless instructed otherwise. Please let me know if I should stay at version 15.

 

Best Regards

Bernd

 

 

From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Wayne Beaton
Sent: May-10-17 11:59 AM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: Re: [cross-project-issues-dev] Guava versions in Oxygen

 

Sam's interpretation is technically correct, but we don't do that in practice.

You only need a PB for third party content that you redistribute.

We've made some progress on eliminating PBs (at least in the OSGi context), but we're not there yet.

Wayne

 

On 08/05/17 03:34 PM, Ed Merks wrote:

No, my reading is that you need a PB CQ for what you redistribute.  Of course the need for a PB CQ is questionably stupid at best in the first place and I've offered to automate the whole process of tracking such dependencies.   But alas, to no avail...

 

On 08.05.2017 20:58, Sam Davis wrote:

Whether you need a PB is debateable. My reading of the words is that you need a PB for anything any configuration might use.

 

I hope that is not the correct reading because it would imply that if you have open version ranges you need a PB for every version that will ever be released in the future, since it *could* someday be used. This is of course not possible...

Sam





_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev






_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

 

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation




_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

 

 

Virus-free. www.avast.com