[project] Major version change to 4.0

[eclipse-ocl-bot]

| --- | --- |
| Bugzilla Link | 358558 |
| Status | CLOSED FIXED |
| Importance | P3 major |
| Reported | Sep 22, 2011 07:16 EDT |
| Modified | May 20, 2013 11:36 EDT |
| Version | 3.1.0 |
| Blocks | 360569 |
| Reporter | Ed Willink |

Description

MDT/UML2 plans a major version change to 4.0 for Juno, therefore at least the UML depenedent plugins should have a major change. Plugins should be consistently versioned across the project, so all plugins should have a major version change. I think we have no choice.

As an externally imposed change and associated Eclipse policy compliance, and the need for version consistency, I plan to commit these changes fairly promptly. Probably today.

I may take the opportunity to change Pivot URIs in the examples to 4.0 as well.

[eclipse-ocl-bot]

By Ed Willink on Sep 22, 2011 07:51

EMF 2.8 has some lowerbound dependencies on the '3.8' platform so there appears to be no chance that MDT/OCL can run on Indigo as from Juno M2.

Also, hopefully a temporary bug, EMF 2.8 is contributing rebuilt 2.7 and 2.6 plugins whose changed dates blows away the Indigo EPP expectations. I think that this conforms that trying to 'preserve' old unchanged plugins is more trouble than it's worth. If someone wants to use any MDT/OCL 4.0 plugins, they must use
4.0 plugins throughout; there is no saving to users in allowing some 3.1s. The only saving is on optimized downloads, but I'm not sure how many download areas are able to avoid replicating a 3.1 plugin in a 4.0 site anyway.

[eclipse-ocl-bot]

By Ed Willink on Sep 22, 2011 09:26

This is on hold while we discover whether it's really necessary.

In the interim for M2, we will widen our UML2 depenedencies to [3.0.0, 5.0.0)

[eclipse-ocl-bot]

By Ed Willink on Sep 22, 2011 15:30

[3.0.0, 5.0.0) is decitful since UML2 changes URI from ...3.0.0/UML to 4.0.0/UML without (inM2) providing transition capabilities. The UML package name also changes from "uml" to "UML", some model classes come and go and inherited validation constriants function name evolve.

Therefore we plan to contribute a UML dependency change to [4.0.0,5.0.0) as soon as possuible, suppressing API checking.

Perhaps tomorrow we will make the major increment to 4.0.0 for all MDT/OCL plugins and features.

Downstream projects are advised to change the upper MDT/OCL bound to 5.0.0) now and perhaps delay raising the lower bound to 4.0.0 until M3.

(Still hoping that Ed Merks can justify not changing the major version.)

[eclipse-ocl-bot]

By Mariot Chauvin on Sep 22, 2011 18:10

(In reply to comment #0)

MDT/UML2 plans a major version change to 4.0 for Juno, therefore at least the
UML depenedent plugins should have a major change.

I think and hope only OCL example plug-ins depends on UML.

Plugins should be
consistently versioned across the project, so all plugins should have a major
version change.

Could you post me to a link where it is written that all plug-ins should be consistently versioned across a project/feature. I was not aware of this recommendation or rule. I know at least 2 projects including in the release train which do not seems to follow it : The platform and EMF.

I think we have no choice.

As an externally imposed change and associated Eclipse policy compliance, and
the need for version consistency, I plan to commit these changes fairly
promptly. Probably today.

I may take the opportunity to change Pivot URIs in the examples to 4.0 as well.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Sep 22, 2011 18:22

Ed,

The build carries on failing in a late phase. The error is meaningless to me and I prefer to look into it at work with a more suitable environment (IDE, workspace, etc).

I'd prefer to do the version increasing after M2 (to avoid downstream project headaches) but if we have no choice due to UML-binding anomalies, we still have some days to try to sort them out.

P.S: We finally have a new chance to do the proper and desired OCL features and plugins reorganization.

Regards,
Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Sep 23, 2011 02:23

(In reply to comment #4)

I think and hope only OCL example plug-ins depends on UML.

No. o.e.ocl.uml and o.e.ocl.uml.edit depend on UML.

Unfortunately the traditional OCL code was very tightly coupled.

The Ecore-binding provides an OCL meta-model that is extended from Ecore so is tightly coupled to Ecore. (OCL re-publishes Ecore APIs.)

The UML-binding provides an OCL meta-model that is extended from UML so is tightly coupled to UML. (OCL re-publishes UML APIs.)

The new Pivot-binding provides an OCL meta-model that is derived from UML models, no tight coupling to the UML2-project; just uses UML2... converters.

For QVTd I started on the same approach and hit difficulties with the double inheritances of Package/Class in Transformation and Parameter/Variable. This is when I learnt the Ed Merks dictum; do not extend Ecore. For QVTd I therefore started to decouple.\

Plugins should be
consistently versioned across the project, so all plugins should have a major
version change.

Could you post me to a link where it is written that all plug-ins should be
consistently versioned across a project/feature. I was not aware of this
recommendation or rule. I know at least 2 projects including in the release
train which do not seems to follow it : The platform and EMF.

I'll try to find it again; originally found it when first rationalising and finding MDT/OCL 1.x and 2.x combined for UML's 3.x major change.

Consistency is for major versions of changed plugins, so minor versions can mix and unchanged versions can persist, but may need additional 0.100's.

Acceleo has a loosely coupled architecture for multi-version OCL usage, so since it does not republish OCL APIs, Acceleo probably doesn't need a major version change.

(In reply to comment #5)

I'd prefer to do the version increasing after M2 (to avoid downstream project
headaches) but if we have no choice due to UML-binding anomalies, we still have
some days to try to sort them out.

P.S: We finally have a new chance to do the proper and desired OCL features and
plugins reorganization.

Yes, but a final M2 contribution with disabled API checking for UML is undersiable, and if downstream projects are going to take a UML/EMF/e4 hit, I think it's best to put the OCL hit in at the same time.

I don't think we can avoid QVTo being hit now by UML. The EMFq hit might be deferable but I think it's unavoidable before Juno.

I don't think we can do the feature re-organisation until the Core/Tools are separately built. No way for M2, perhaps M3, perhaps M4 when we might try the examples promotion.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Sep 23, 2011 04:04

I'll try to find it again; originally found it when first rationalising and
finding MDT/OCL 1.x and 2.x combined for UML's 3.x major change.

Consistency is for major versions of changed plugins, so minor versions can mix
and unchanged versions can persist, but may need additional 0.100's.

http://wiki.eclipse.org/Version_Numbering

I don't think we can do the feature re-organisation until the Core/Tools are
separately built. No way for M2, perhaps M3, perhaps M4 when we might try the
examples promotion.

I'm not sure they are exclusive tasks, but I agree that it's better not starting a new task prior to finishing the previous one.

Regards,
Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Sep 23, 2011 05:39

I think the flaw in my logic applies to the implication to sibling plugins.

UML2 goes to 4.0 so o.e.ocl.uml plugin must go to 4.0
so all features transitively including o.e.ocl.uml must go to 4.0

but other plugins CAN stay at 3.x although featured as 4.x.

When a major increment for a residual 3.x plugin occurs (that also affects a 4.x) plugin then both go to 5.x; just as we did for 1.x Ecore-OCL, 2.x UML-OCL to 3.x.

So we change the UML plugins and almost all features to 4.0, but leave almost all plugins at 3.2. This could leave downstream projects unaffected.

Roll on UML 2.5, OCL 2.5 when we might renormalize at 5.0.

[Shouldn't the license feature plugin also be 4.0 rather than 1.0?]

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Sep 23, 2011 05:55

Ed,

(In reply to comment #8)

I think the flaw in my logic applies to the implication to sibling plugins.

UML2 goes to 4.0 so o.e.ocl.uml plugin must go to 4.0
so all features transitively including o.e.ocl.uml must go to 4.0

but other plugins CAN stay at 3.x although featured as 4.x.

This sounds good to me.\

When a major increment for a residual 3.x plugin occurs (that also affects a
4.x) plugin then both go to 5.x; just as we did for 1.x Ecore-OCL, 2.x UML-OCL
to 3.x.

Perhaps we didn't do right. Any reason about why do we need to increase 3.x to 5.0 ?... just aligning versions ?. A good question to ask and receive more feedback.

So we change the UML plugins and almost all features to 4.0, but leave almost
all plugins at 3.2. This could leave downstream projects unaffected.

This sounds good to me.

Roll on UML 2.5, OCL 2.5 when we might renormalize at 5.0.

[Shouldn't the license feature plugin also be 4.0 rather than 1.0?]

That's a good question I've always had... It's the first version of the plugin, so why should it start in 4.0, or 3.1 (when it was created) ? Another question to ask and receive feedback.

P.S: I don't know why the build can't pacakage the SDK... I'm running a new build "echoing" variables which are involded in the offending ant task to see if there is any weird one.

Regards,
Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Sep 23, 2011 06:21

This is a nightmare.

(In reply to comment #9)

but other plugins CAN stay at 3.x although featured as 4.x.

This sounds good to me.

It's good today, it's dreadful tomorrow.

All users of 3.x plugins must use [3.x,4.0) bounds while for 4.x plugins they must use [4.x,5.0). Confusing. [3.x,5.0) would be bad because that is implying that a major increment isn't major, so a 3.x plugin can never have a major increment to 4.x.

So we change the UML plugins and almost all features to 4.0, but leave almost
all plugins at 3.2. This could leave downstream projects unaffected.

This sounds good to me.

Of course the release name and ZIPs and update site are also 4.0, not 3.2, so users are using lots of 3.2 but it's always called 4.0. You find a 3.2 plugin in a 4.0 ZIP!

[Shouldn't the license feature plugin also be 4.0 rather than 1.0?]

That's a good question I've always had... It's the first version of the plugin,
so why should it start in 4.0, or 3.1 (when it was created) ? Another question
to ask and receive feedback.

I think this is simple, a major increment (or initial value) should always be the new project-wide upper bound.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Sep 23, 2011 06:43

(In reply to comment #10)

This is a nightmare.

(In reply to comment #9)

but other plugins CAN stay at 3.x although featured as 4.x.

This sounds good to me.

It's good today, it's dreadful tomorrow.

All users of 3.x plugins must use [3.x,4.0) bounds while for 4.x plugins they
must use [4.x,5.0). Confusing. [3.x,5.0) would be bad because that is implying
that a major increment isn't major, so a 3.x plugin can never have a major
increment to 4.x.

So we change the UML plugins and almost all features to 4.0, but leave almost
all plugins at 3.2. This could leave downstream projects unaffected.

This sounds good to me.

Of course the release name and ZIPs and update site are also 4.0, not 3.2, so
users are using lots of 3.2 but it's always called 4.0. You find a 3.2 plugin
in a 4.0 ZIP!

I'm not sure what's the problem... This is common, as Mariot commented take a look to other important projects, such us EMF and Platform. Indigo EMF features are 2.7, however there coexist 2.5, 2.6, and 2.7 plugins, all of them inside of EMF 2.7 zips. We may discuss about quite confusing this is, but it undoubtedly don't create any headache to me and it follows the general plugin and features version numbering.

[Shouldn't the license feature plugin also be 4.0 rather than 1.0?]

That's a good question I've always had... It's the first version of the plugin,
so why should it start in 4.0, or 3.1 (when it was created) ? Another question
to ask and receive feedback.

I think this is simple, a major increment (or initial value) should always be
the new project-wide upper bound.

Where is this "rule" stated ?.

Regards,
Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Sep 23, 2011 07:17

Version change to 4.0 UML plugins and features pushed to master. This
re-instates the API checking.

Adolfo: you should pick this up on your next build, which looks like it may be
soon. If you can get a build, please contribute as OCL 4.0M2.

I'll now work on the UML JUnit failures.

Awaiting advice from cross-project-dev posting as to whether we go to 4.0 for
all plugins.

[eclipse-ocl-bot]

By Ed Willink on Sep 23, 2011 07:21

(In reply to comment #11)

I'm not sure what's the problem... This is common, as Mariot commented take a
look to other important projects, such us EMF and Platform. Indigo EMF features
are 2.7, however there coexist 2.5, 2.6, and 2.7 plugins, all of them inside of
EMF 2.7 zips. We may discuss about quite confusing this is, but it undoubtedly
don't create any headache to me and it follows the general plugin and features
version numbering.

But they're all 2.x. What if EMF ecore was all 2.x but xmi was 3.x? Plenty of time to discuss this one.

I think this is simple, a major increment (or initial value) should always be
the new project-wide upper bound.

Where is this "rule" stated ?.

Sorry 'should' is just my opinion; it seems obvious, but much the least of our troubles, and not one that needs fixing today if at all. One could argue that the license feature number should be the license version number.

[eclipse-ocl-bot]

By David Williams on Sep 23, 2011 07:44

Here's a few quick observations ...

new plugins should be 1.0 (in nearly all cases). (But, admit not everyone does,
and it is not hugely harmful to name it something else, since new, but ... it
is new ... so should start at 1.0).

It is becoming increasingly common for mature projects to have bundles at a
wide variety of version levels. This may seem confusing, but in practice, I
don't think that bad. Its pretty important, for correct modularity, that each
bundle "be its own thing" and not be artificially coupled with other bundles,
for the simple reason of getting their version numbers to match.

features increment based on the largest increment in their contained bundles.
So, for the sake of illustration, let's say you had a feature at 5.5, and if it
had one bundle that has a major increment, say, from 3.x to 4.0, then the
feature would go to 6.0, reflecting the "major increment".
In practice, that should not effect too many people, if consumers are
specifying constraints at the bundle level instead of the feature level.

While confusing, and complicated, it is also simply the way evolution is, over
the course of mature projects ... so welcome to being a mature project :)

Take my comments with a grain of salt ... since I'm not familiar with your code
and might be misinterpreting much of what I've read quickly. But, as a general
rule, making the least number of changes to version levels is far better than
prematurely updating versions just to be consistent.

Hope that helps,

p.s. you mentioned your build and zips on mailing list ... I did look, but
didn't see anything obvious (though, I'm not that familiar with buckminster
based builds). If you were just going to experiment, though, you might try
running on 'master' instead of 'slave1' but there is almost a zero percent
chance that would fix anything. (and, if it did, would just help isolate what
the real error was). Good luck.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Sep 23, 2011 07:53

Ed,

Some lines of the more clarifying org.eclipse.platform 3.7 feature:

Includes 1.x, 2.x and 3.x features as same as 1.x and 3.x plugins...

BTW, looking at this feature, I have the feeling that new plugins for the Eclipse Platform are created using the 1.0.0 version ... parhaps, looking at the date in which org.eclipse.core.net plugin was created, we could have the answer.

Regards,
Adolfo.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Sep 23, 2011 07:56

David,

Thanks for the helpful information... Concerning the build, I'll try the master server option... although I'm not very optimistic :(

Regards,
Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Sep 23, 2011 09:11

(In reply to comment #14)
Thanks David

It is becoming increasingly common for mature projects to have bundles at a
wide variety of version levels.

It seems like the sooner our version numbers are a serious mess the sooner we can stop worrying about tidiness.

In that case, when we promote the examples plugins, they can become 1.0 ensuring a good mix.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Sep 23, 2011 11:46

Ed,

Looking at our produced repository I miss some 4.0.0 minor versions in the following features:

org.eclipse.ocl.master
org.eclipse.ocl.all.sdk

Concerning the build... I've disabled the ZIPs packaging... no clue about what is happening, yet.

[eclipse-ocl-bot]

By Ed Willink on Sep 23, 2011 12:48

Resurrecting lost discussion off-bug:

Ed wrote
--------
Hi Adolfo

I recomputed a couple of feature include dependencies, but missed ocl.edit.

Most of the features have no explicit dependencies.

David: Do we really need them? They seem to just be there to break the aggregator.

Adolfo wrote
------------
I think so ... these prevents the feature being installed if those dependencies are not previously installed in the platform.

The features you mention (which don't have dependencies) are probably those which don't include any plugin but other features

David wrote
-----------
es, definitely do NOT want feature-to-feature dependencies, unless there is are really good reason. Maybe I'm misunderstanding ... but, yes, you may be making life hard for yourselves :) ... but I do not think you need to do a "recompute of feature includes" ... that was more for old update manager ... now p2 figures all that out for you.

--------------------------------
I do not know the design intent for the feature dependencies. The requirements of the old Update Manager certainly seems plausible.

If anything the features with computed dependencies are the most not least dependent.

Since David says they're probably obsolete, I know of no utility, the latest aggregator run has failed because they're still wrong, let's just delete the lot.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Sep 23, 2011 13:04

Ed,

If it's obsolete, why Eclipse Platform has recently changed the EMF features inclusion as a EMF features requirement ? [1]

I'd need some documentation and/or more opinions.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=356644

Regards,
Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Sep 23, 2011 13:13

I think require/include is a different issue. The platform now bundles some EMF plugins so has to 'fetch' them.

This is the same scenario as LPG bundling from Orbit for us.

For EMF, UML2, platform, Xtext ec, we just reference them from plugin manifests and let p2 figure it out.

So yes perhaps we should have one dependency on LPG.

[eclipse-ocl-bot]

By Axel Uhl on Sep 24, 2011 15:56

As per Ed's request, I'm looking at the changes in the core plugins that were already merged into the master branch. From what I see, there are the following types of changes:

• reactions to changes in the UML metamodel, leading to altered generated artifacts, such as the change from reference to containment for ownedElements; these all seem ok

• changes to versions in manifests and @SInCE in Javadocs; this also all looks good

• addition of the getMetametaclass method in EcoreTestReflection for usage in UML tests; looks good

• changes in how the UML tests are set up, particularly affected is UMLTestReflection; there are some significant changes in how the resource set's URI map is "primed" with plugin URIs. What's the reason for these changes?

• commit cb07c5a has significant white space only changes for OCL.ecore. Why?

• JUnit plugin tests for OCL/UML are disabled based on bug 358801 / 358759. Seems ok and without alternative for now.

+1

[eclipse-ocl-bot]

By Ed Willink on Sep 24, 2011 16:51

(In reply to comment #22)
Thanks for the prompt review.

• changes in how the UML tests are set up, particularly affected is
  UMLTestReflection; there are some significant changes in how the resource set's
  URI map is "primed" with plugin URIs. What's the reason for these changes?

The existing tests just use 'the' UML metamodel as a convenient complex test model. In UML 2.3 the metamodel was a bit vague either EMOF or CMOF. In UML 2.4 it is UML, so there is a large metamodel of a UML model, and a small self-describing metamodel that defines the large metamodel. UML2 4.0.0 has provided the small meta-model as 'the' meta-model, so tests using the large meta-model fail. The large meta-model is only available in a different plugin and, as Hudson made clear, is not available in the binary plugin.

I tried to use MWE classpath technology to obsolete the launch arguments, but some arguments define system properties accessed by OCL.initialize (aargh! API compatibility). So my attempts to clean up failed.

The init is a mess/ I don't even know how the ../.. works on Hudson. I was lucky to find it before getting stuck by the missing binary content.

When the missing meta-model bugzilla 358801 / 358759 is fixed we can maybe do better.

• commit cb07c5a has significant white space
  only changes for OCL.ecore. Why?

The primary model sources, OCL.uml, OCLCST.uml and OCLUML.uml were upgraded and used to regenerate the Ecores. A couple of uses of the wrong String primitive type/missing stereotype were necessary in OCL.uml. The resulting Java was then pleasantly unchanged after reorganising imports.

[eclipse-ocl-bot]

By Ed Willink on Nov 07, 2011 15:27

UML2 plugins changed to 4.0.0 for M2.

[eclipse-ocl-bot]

By Ed Willink on May 20, 2013 11:36

CLOSED after a year in the RESOLVED state.