Yup. we talk about "marketing numbers/names" as distinct from the
actual version numbers. For example, much of Equinox now has version
numbers all over the map. For the most part we have started talking
about our "Galileo release" as using something like "3.5" does not make
sense for us across the board. Perhaps we need a way of actually
capturing this notion...
Jeff
David M Williams wrote:
> 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?
"Project Release Number" isn't
really a concept when it comes to versioning rules ... just
plugins and features. Typically a
"Project
release" would following the numbering
of it's highest versioned feature
(or
plugin, if no features) but you are free
to call it what ever you (and your
committers,
and clients) would like.
Some people attach a numerical
meaning
to the "Project release number"
but others of us don't, seeing it as
part of a marketing name.
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
http://www.eclipse.org/dsdp/tm
From:
cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]
On Behalf Of Christian W. Damus
Sent: Wednesday, September 24, 2008 5:23 PM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: [cross-project-issues-dev] Version Numbering:
Feature/Plug-in
vsProject/Release
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
[1] http://wiki.eclipse.org/index.php/Version_Numbering
--
Christian W. Damus
Senior Software Developer, Zeligsoft Inc.
Component Lead, Eclipse MDT OCL and EMF-QTV
E-mail: cdamus@xxxxxxxxxxxxx
_______________________________________________
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
E-mail: cdamus@xxxxxxxxxxxxx
_______________________________________________
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
|
