| ICU plugin in 4.3 SR2 breaks compatibility [message #1271140]
||Fri, 14 March 2014 06:41
| Vlad Dumitrescu
Registered: July 2009
I'm not 100% sure this is the right forum and I couldn't find anyone else reporting this.
If I am reading the changes properly, the Kepler SR2 update includes a com.ibm.icu plugin that changed version from 4.4 to 50.1.1. This breaks plugins that were built against older versions and expect ICU version to be in the [4.4.0, 5.0.0) range: they can't be installed in SR2.
Is it just me being confused, or is it a real problem? Shouldn't this upgrade have waited until Luna?
What can we do about it? The only alternative for me is to make available multiple update sites, but it's a lot of work for something that IMHO shouldn't have happened...
[Updated on: Fri, 14 March 2014 06:55]
Report message to a moderator
|Re: ICU plugin in 4.3 SR2 breaks compatibility [message #1279720 is a reply to message #1271140]
||Sat, 29 March 2014 01:42
| David Williams
Registered: July 2009
On 03/14/2014 06:41 AM, Vlad Dumitrescu wrote:|
> I'm not 100% sure this is the right forum and I couldn't find anyone
> else reporting this.
> If I am reading the changes properly, the Kepler SR2 update includes a
> com.ibm.icu plugin that changed version from 4.4 to 50.1.1. This
> breaks plugins that were built against older versions and expect ICU
> version to be in the [4.4.0, 5.0.0) range: they can't be installed in
> Is it just me being confused, or is it a real problem? Shouldn't this
> upgrade have waited until Luna?
> What can we do about it? The only alternative for me is to make
> available multiple update sites, but it's a lot of work for something
> that IMHO shouldn't have happened...
> best regards,
I don't want to be argumentative, but I checked, and from what I see,
version 50.1.1 was in each release of Kepler. At least, as delivered
specifically by the Eclipse Platform team.
Perhaps earlier you were building on top of something else? If you do
something like build against the whole "Kepler Simultaneous Release"
repository, then it would have been some other project that was
contributing that old version to that repository and then they
eventually stopped doing that.
Which brings me to another piece of advice I always give -- which may or
may not apply to what you do -- but I always advice people to build
against the repositories of the specific projects they need. The
Simultaneous Release repo is intended more for "installing from", not
"building against" .... though, I know hardly anyone follows my advice
in this area. :) If that is what happened to you ... perhaps you could
help spread the word about the risks of doing that.
All that said, we've always tried to caution people about third-party
bundle versions, especially "com.ibm.icu". As a class, they do not
always follow the semantic versioning rules we do in Eclipse. For
com.ibm.icu, in particular, we encourage people to to specify a lower
bound only. In part, this is because we know first hand the ICU project
is quite focused on compatibility from release to release ... for their
APIs anyway, though they have made "odd" changes in versioning several
times over the years. But in general, third party bundles are always a
little unpredictable in this way ... some of them make breaking API
changes going from minor release to minor release. I can only advise you
open a bug on those third parties, asking them to follow semantic
Hope this helps explain things ... even though I have no "solution"
other than what you suggested. But when you do update that plugin, I'd
just leave the lower bound of 4.4.0 and not specify an upper bound (but,
again, this is not be good advice for all third party bundles ... it's
meant to be specific to com.ibm.icu.
Powered by FUDForum
. Page generated in 0.02434 seconds