| Hi, Martin,
Yes, that's the case: the OCL-for-UML feature is not a dependency of anything else in the OCL project.
I like your suggestion of co-releasing a 1.3 and 2.0 version of the UML support. As the OCL features that I am planning for Galileo do not depend on UML, particularly, they should be applicable to both versions. I am also planning some refactoring of features, so this just might work.
Thanks to you, David, and Ed for your helpful responses!
Cheers,
Christian
On 24-Sep-08, at 2:51 PM, Oberhuber, Martin wrote: Hi Christian, So you need to keep your OCL-for-UML2 component with the OCL project. From what you say, it looks like the rest of OCL doesn't depend on the OCL-for-UML2 integration/add-on/component. Given that this is an add-on to your core framework offering, I'd think that it is in order when your core framework releases 1.3 and you release a 2.0 version of the add-on at the same time. I'm not sure if it's feasible, but perhaps you could even release an "old" version of your integration, based on the older UML, at the same time such that you'd have both a 2.0 and an 1.3 version of your integration? Assuming that your 1.3 framework doesn't break compatibility, the old integration which used to run on 1.2 should still run fine on 1.3 if anybody needs that. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member Hi, Martin,
Thanks for replying. You make an interesting suggestion, and clearly I left out some important details.
This "integration" is a binding of the OCL Abstract Syntax to the UML metamodel, basically implementing the OCL metamodel in UML terms; we have a similar plug-in that implements OCL for Ecore. At the risk of spewing esoterica, I should explain that these plug-ins effectively implement the Eclipse near-equivalents of the CompleteOcl and EssentialOcl languages, which are specified by OMG as extensions of the EMOF and UML metamodels, respectively, for which the Eclipse (near-)implementations are Ecore and UML2, respectively. The dependency that is breaking API compatibility is UML2, by force of incompatible changes in their OMG spec.
I think that "integration" isn't the right word, as these plug-ins are really more about providing an OCL implementation for a particular metamodel, rather than "integrating" capabilities of the two projects. The nature of the dependency is API extension: the public interfaces of OCL-for-UML extend the public interfaces of UML2, as this is mandated by the OMG specification. Although it certainly would resolve my current conundrum, I don't think it would make sense for the EMF and UML2 projects to host these OCL implementations, as the dependencies would be quite difficult for them to manage.
Anyhow, I was hoping to address the general question of the relationship between project versions and plug-in versions. Is there any relationship defined? Have other projects faced a question like this? Or, will nobody blink if a project that was intending to release as 1.3 turns out to be a version 2.0 that looks and feels like a 1.3?
Cheers,
Christian On 24-Sep-08, at 11:57 AM, Oberhuber, Martin wrote: Hi Christian, it seems odd to me that your integration re-exports that other modeling project... ...would it make sense to move your integration into the realm of the other project that it extends? In that other scope it would be natural to have your integration's major version bumped up, give you the chance to remove the reexport if you want, and leave the rest of OCL in a sane state... Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member 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
-- 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
-- Christian W. Damus Senior Software Developer, Zeligsoft Inc. Component Lead, Eclipse MDT OCL and EMF-QTV
|
