|Re: [cross-project-issues-dev] [Bug 547338] Update to guava 24.1.1+(fix CVE-2018-10237)|
We at Xtext are affected by this. And we align to the release Train although our RC1 is ususally the final release.
And we have very very limited capacity to work on anything. The Problem is that we cannot estimate the work (testing, Adaption) and having support for the new Version only would break older target platforms like Oxygen. Also we need to investigate how that interferes with Google Guice (used for injection, if update needed there too additional bureaucracy work with the foundation needed). Thus I preferr to do such things before M1 and not somewhen between M3 and a RC.
Gesendet von Mail für Windows 10
This affects quite a few projects (Xtext comes to mind) and we know from past experience that shipping multiple versions of a library that's mostly resolved using package requirements (rather than bundle requirements) can result in problematic wiring resolutions. So generally we've tried to ensure that there is only one version of such a bundle in the release train repo. This seems to suggest that all projects contributing to the release train (and contributing Guava) all ought to use/contribute the same version of Guava and should all test that this works (or even compiles for that matter because Guava has a history of deleting things).
Xtext's releases don't totally line up with those of the release train, so certainly a general move requiring all projects that contribute Guava to the release train all moving to a new version seems problematic; I think Xtext would need to plan a new release for this. And this seems like short notice to me...
On 15.05.2019 21:38, Homer, Tony wrote:
Back to the top