Christian,
I'm suggesting that you put the reasonable version range in your
specific plugin and that everyone else is perfectly able to put their
own direct version range dependencies on UML itself, even though you
export those plugins. I.e., I'm not sure the version guidelines are
ideal with respect to re-exporting. That's just my personal opinion...
Christian W. Damus wrote:
Hi, Ed,
The problem is that I can't reasonably (I think) put a version
range like [2.3.0, 4.0.0) on a dependency that OCL re-exports because
that means that OCL *imports* this range, which isn't practical.
Especially as OCL extends the UML2 model implementation, which is why
it actually declares a rather narrow dependency range.
An option would have been not to re-export the dependency, but
it is a part of the OCL API, so that wouldn't have been right, either.
In any case, my problem isn't with plug-in versioning; that is
well understood and I'm happy with the scheme Eclipse has. The issue
is a matter of perception of what the *project's* version number
communicates to users.
cW
On 24-Sep-08, at 12:08 PM, Ed Merks wrote:
Christian,
I seem to recall this issue having been discussed last year, or maybe
it was the year before when we did the Java 5.0 stuff. I believe that
at that point we concluded that if downstream clients want to be
specific about their range restrictions on the plugin being
re-exported, they always have the option of adding an explicit
dependency on that re-exported plugin and then they can put explicit
version range boundaries on that. But I don't see that encoded in any
of the guidelines, so maybe I'm just confused...
Christian W. Damus wrote:
Hi,
According to our excellent Version Numbering Guide [1], when
a re-exported plug-in dependency increases its major version segment,
the re-exporting plug-in must also increase its major version segment.
This change "bubbles up" to containing features. This is all well.
What the Guide does not address is what the expected impact
(if any) is on the project/release version number. The OCL project in
Eclipse Modeling PMC is targeting a 1.3 release in Galileo without
incompatible API changes from its 1.2 release. However, one of its
features which provides integration of the core API with another
modeling project will have to update to version 2.0.0 because its
re-exported dependency will "soon" change from version 2.2.100 to 3.0.0.
Does this mean that the OCL project should release as 2.0
rather than 1.3 in June? I would be inclined to stick with 1.3 because
- the core OCL API is not undergoing incompatible changes,
only API from a dependency that one of its integration features
extends. I don't want to give an impression of major churn
- the particular changes of concern in the dependency are in
API that is not used in the context of OCL, and so will not actually
affect binary compatibility (but only installability) for OCL users
However, I do understand that it could be confusing to OCL
users to see plug-ins versioned as 2.0.0 in a 1.3 release. This was a
hot discussion topic in the early days of Java™ 2 version 1.2 and
latterly 5.0, etc. that we may not want to repeat.
Does anyone know of a precedent here at Eclipse? Any
comments are welcome.
Thanks,
Christian
--
Christian W. Damus
Senior Software Developer, Zeligsoft Inc.
Component Lead, Eclipse MDT OCL and EMF-QTV
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Christian W. Damus
Senior Software Developer, Zeligsoft Inc.
Component Lead, Eclipse MDT OCL and EMF-QTV
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
