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