Hi
The Eclipse Versioning rules are strong; annoying and arguably not even
strong enough.
The last UML major version change forced OCL to make a major version
chnage even though it wasn't necessary from an OCL point of view.
However OCL took the opportunity to remove UML from the re-exported API
so that the next UML version change will not mandate an OCL version change.
Whenever you choose to re-export another project's bundle, you decide to
be tightly coupled to that project; any major change in the referenced
project mandates a major version change in the re-exporter. For primary
platform and EMF plugins it is obviously impractical to avoid a tight
coupling so why bother. But for secondary facilities such as EMF codegen
or EMF compare, hiding the dependency may be highly beneficial. Thus
Guice and Guava should never be re-exported.
But Xtext is almost uniquely troublesome since the autogeneration of
code for the user imposes a requirement for both backward and forward
compatibility. With such a rich API, Xtext would be frozen if it really
imposed perfect API compatibility. EMF has a similar problem that is
largely solved by a run-time compatibility level genmodel option.
Injection perhaps makes Xtext's API too rich to realistically do the same.
Even the platform has now decided that a major version change to 4.x
plugins is too horrible and so there are regular announcements of
removal of long-deprecated API. The removal totally violates versioning
policies.
Xtext similarly needs to follow a pragmatic policy. In practice Xtext
2.3 and Xtext 2.8 involved breaking changes that actually mandated major
version changes.
org.eclipse.xtext currently re-exports com.google.inject but not
org.objectweb.asm
org.eclipse.xtext.util currently re-exports com.google.inject and
com.google.guava
Too late for Xtext 2.15.
It could be announced that in Xtext 2.16 all usage of Guava/Guice/... in
interfaces will be deprecated. Alternative API must be provided. This
can be developed and tested by removing the re-exports and escalating
all non-API-in-interface warnings to errors. However in the Xtext 2.16
release the re-exports must remain.
It could also be announced that in Xtext 2.18 all re-exports of
Guava/Guice/... will terminate (without a major version change). The old
deprecated API could remain for much longer but would only work for
users who avoid inconsistent Guava choices.
Currently OCL's editors do not impose a Guava version preferring to
allow the re-exported Xtext version to be used avoiding an
incompatibility. Once Xtext stops re-exporting, OCL's editor plugins
will have the freedom to choose a different version to Xtext's plugins.
In the past this was really bad, but if there is no leakage of Guava in
interfaces, perhaps this problem is also solved. OCL's editor plugins
can then, albeit accidentally, use a different Guava version to the
underlying Xtext support plugins.
I am not aware of any Guava in Xtext interfaces that OCL uses, so once
the missing imports are added, OCL editors should remain compatible
across a broad range of Xtext releases. Deferring the removal till Xtext
2.18 without a major version change follows the
two-releases-notification that the platform now uses.
Regards
Ed Willink
On 03/09/2018 07:22, Sven Efftinge ([email protected]) wrote:
Hi Christian,
those libraries are used by users, so those changes will be exposed to
them. I haven't looked closely into what API has changed in those
versions, but if they have bumped the major version, there might be
something in it that breaks. I assume they follow semantic versioning,
too.
That said, bumping Xtext's major version will be a huge problem for
Eclipse clients, because older existing versions will not work with
it. And because we have singleton plug-ins in every Eclipse
installation there can be only one version of Xtext. We have discussed
this for years. Bumping the major version is a bad idea.
Sven
Am Sa., 1. Sep. 2018 um 14:31 Uhr schrieb Christian Dietrich
<[email protected] <mailto:[email protected]>>:
Hello guys.
i need your assistance with regards the rules op api changes and
version
bumps.
if we increase our dependency at Xtext to Guice 4.x and Guava 23.x
would
that require a Xtext 3.0? i am not sure if binary compatibility is
given
by such a change.
Thanks
Christian
--
Christian Dietrich (Diplom-Informatiker (BA))
Softwareentwickler / -Architekt
Tel.: +49 (0) 711 / 34 21 91-0
Fax.: +49 (0) 711 / 34 21 91-29
Mobil: +49 (0) 151 / 173969 17
Mail: [email protected]
<mailto:[email protected]>
XING: https://www.xing.com/profile/Christian_Dietrich8
Web: http://www.itemis.de
Skype: christiandietrich1982
ICQ: 125801794
itemis AG
Niederlassung Süd
Industriestraße 6
70565 Stuttgart
Rechtlicher Hinweis:
Registergericht: Amtsgericht Dortmund HRB 20621 | Sitz der
Gesellschaft:
Lünen
Vorstand: Jens Wagener (Vorsitzender) | Wolfgang Neuhaus
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.) | Michael Neuhaus |
Jennifer Fiorentino
_______________________________________________
modeling-pmc mailing list
[email protected] <mailto:[email protected]>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
_______________________________________________
modeling-pmc mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
modeling-pmc mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
