Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] EMF Plug-in Versioning and Reexported Dependencies


John,

Given this advice combined with our intent to provide binary compatibility, this argues that we should name our next version 2.3 not 3.0.  So we are reconsidering our planned numbering scheme.   In general, as long as the erased 2.3 API is identical to the original 2.2 API, it should definitely be binary compatible.

I look forward to hearing your  thoughts on the exported import version range issue.


Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265  (t/l 969)




John Arthorne/Ottawa/IBM@IBMCA
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

10/20/2006 12:03 PM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

To
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject
Re: [cross-project-issues-dev] EMF Plug-in Versioning and Reexported        Dependencies






> Does anyone care to provide arguments whether templatizing an API in a binary compatible way is a major or
> minor version change?

I think this is a minor version change (when done right). The example of java.util collections shows that this can certainly be done in a compatible way without any effect on existing clients.

(still thinking about the version numbering dillemma)
John


Ed Merks/Toronto/IBM@IBMCA
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

20/10/2006 07:02 AM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

To
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject
Re: [cross-project-issues-dev] EMF Plug-in Versioning and Reexported        Dependencies








David,


>Ok, you asked for it ... so ....
Oh oh!

>but how about option 3? Remove the re-exports if they are not part of _your_ API, but
>provide a compatibility layer for binary compatibility.

The problem is they effectively are part of the API, but I'm not sure the rule says you should/can/may export if they are part of the API.  For example EList provided by org.eclipse.emf.common is used everywhere; we don't expect ever to change this interface.  Another example is org.eclipse.emf.common.util.URI, which is extensively used in our APIs; we do make changes to this quite regularly, but it's a final class, so who could be broken?

>I've seen this re-export practice (mis)used quite a bit in some rather large plugin stacks, basically causing
>complicated "hidden" dependancies. (not necessarily directly related to your practice, just the practice in general).

I think the rules say don't export unless necessary and then don't define the necessary reasons. ;-)

>And, I think issues caused from these unnecessary re-exports will only get worse as interdependencies get more complicated,
>and especially as people start to use more Import-Package instead of Bundle-Require -- they may _really_
>not need the other stuff you re-export if they have some very limited dependancy.

Just what we need, package level versioning and package level imports to make an already complex problem even more fun! ;-)  Aren't we having enough fun already?

>We in WTP would be willing to adjust to this change, if/when we move to your major
>incremented version (and we likely would, as long as there's no (other) effects to our adopters).

We're still have some discussions about whether our next version really should be EMF 2.3 verses 3.0.  Obviously there will be major API changes, but if we do a good job, they should be binary compatible and 1.4 source compatible, although they will not be 5.0 source compatible despite being binary compatible.  Does anyone care to provide arguments whether templatizing an API in a binary compatible way is a major or minor version change?  Oh dear, am I asking for it again? ;-)

>I'd love to hear other's opinions too, and, of course, you'd want to check with your
>other major product adopters! :)  

Yes, the silence has been quite striking so far.  We should have added the caveat, if you say nothing, you are implicitly choosing option 1.

>The compatibility option might get complicated, but you could probably almost automate it.
>The "compatibility layer" option, would have new non-re-exported versions having new names, and the
>plugins with old names import the new, and re-export them and re-export what ever they did before,
>that would, provide a binary compatible non-breaking changes ... and those that adopt to the
>new versions could completely omit the compatibility layer in their product installs,
>when they were ready.

Ouch.  This sounds painful.  :-(

>If you go with the non-breaking compatibility layer. creating new plugins
>with different names, you could also correct your naming scheme, so it the new stuff would
>be "org.eclipse.modeling.emf"? :)

Correct
your naming scheme! There's no rule that says the package name must match the top level project name.  Certainly package renaming would not serve the community well and certainly everything in the modeling project will not be renamed...

>Oh, and by the way, if you go with the compatibility layer, I'd just go with the easiest version number scheme possible.
>I don't think strict versioning rules would be required for basically a temporary solution.

I can't say I'm fond of this idea at all.  But then you kind of guessed that ahead of time, didn't you. ;-)

Unless we hear screams, I'm tempted to choose option 1.  But I suspect folks will just scream later and that this might cause permanet damage to my hearing.   So that makes option 2, ignore the cascading of version numbers rule, and assume that folks who care will add explicit redundant dependencies.  Once everyone has such explicit redundant dependencies, we could choose option 1 without any impact.  Decisions decisions...



Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265  (t/l 969)



David M Williams <david_williams@xxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

10/19/2006 11:01 PM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>


To
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
emf-dev@xxxxxxxxxxx
Subject
Re: [cross-project-issues-dev] EMF Plug-in Versioning and Reexported        Dependencies










> Any input would be greatly appreciated.


Ok, you asked for it ... so ....
but how about option 3? Remove the re-exports if they are not part of _your_ API, but
provide a compatibility layer for binary compatibility.

I've seen this re-export practice (mis)used quite a bit in some rather large plugin stacks, basically causing
complicated "hidden" dependancies. (not necessarily directly related to your practice, just the practice in general).

And, I think issues caused from these unnecessary re-exports will only get worse as interdependencies get more complicated,
and especially as people start to use more Import-Package instead of Bundle-Require -- they may _really_
not need the other stuff you re-export if they have some very limited dependancy.

We in WTP would be willing to adjust to this change, if/when we move to your major
incremented version (and we likely would, as long as there's no (other) effects to our adopters).

I'd love to hear other's opinions too, and, of course, you'd want to check with your
other major product adopters! :)  

The compatibility option might get complicated, but you could probably almost automate it.
The "compatibility layer" option, would have new non-re-exported versions having new names, and the
plugins with old names import the new, and re-export them and re-export what ever they did before,
that would, provide a binary compatible non-breaking changes ... and those that adopt to the
new versions could completely omit the compatibility layer in their product installs,
when they were ready.

If you go with the non-breaking compatibility layer. creating new plugins
with different names, you could also correct your naming scheme, so it the new stuff would
be "org.eclipse.modeling.emf"? :)

Oh, and by the way, if you go with the compatibility layer, I'd just go with the easiest version number scheme possible.
I don't think strict versioning rules would be required for basically a temporary solution.








Dave Steinberg <davidms@xxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

10/18/2006 11:19 AM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>


To
cross-project-issues-dev@xxxxxxxxxxx
cc
emf-dev@xxxxxxxxxxx
Subject
[cross-project-issues-dev] EMF Plug-in Versioning and Reexported        Dependencies












Hi all,


EMF has a plug-in versioning problem, and I'm looking for some input (especially from those who depend on us) on how we should go about solving it.


We're striving to correctly follow the plug-in versioning guidelines (http://wiki.eclipse.org/index.php/Version_Numbering), which contains this statement:


"Plug-ins re-exporting other plug-ins tie themselves to the re-exported plug-ins, since they are making the re-exported plug-ins part of their API. Therefore, the version of such plug-ins must indicate the most significant type of change between all the plug-ins they re-export and the changes made locally."


EMF re-exports plug-ins extensively.  This was a decision made many years ago, when we really didn't understand what its consequences would be.  As a result, depending on just about any plug-in in EMF automatically pulls in the APIs from just about every other plug-in that it depends on.  Today, it seems the accepted wisdom is, "don't do that!", but unfortunately we've already done it.


The first change I made in our current development stream was to add a method to an API in org.eclipse.emf.common.  Endeavoring to follow the rule, I mapped out the tree of EMF plug-ins that reexport that plug-in.  This is just like the tree you'd see when you click "Show Callers" in the Plug-in Dependencies view, except it only includes dependencies that re-export.  Rather than waste 234 lines to reproduce it in all its glory, I'll just say that it includes almost every last plug-in in EMF.  Trying to propagate version changes through these huge trees of re-exporting dependencies in EMF would be difficult to manage and prone to introducing error.


Moreover, I believe the results would differ only marginally from treating all of EMF as a single monolithic unit, and simply incrementing all of our plug-ins' versions in step each cycle.  And that was precisely the practice that these versioning guidelines were intended to put an end to.


So just following the rules doesn't seem to be a reasonable solution.


After giving it some thought, the EMF team was able to come up with two other possibilities:


1. Remove our re-exports


We could improve the situation simply by removing all the unnecessary re-exports in our plug-ins.  We would have to change our own plug-ins to explicitly require all of their dependencies, which of course wouldn't be a problem. The problem is that this would be a breaking change, probably for almost all of our clients.  The fix would be trivial: just use the excellent PDE tools to explicitly add missing dependencies.  But is that something that people would find overly disruptive?


This should probably be considered a change of API, so we would have to increment the major version numbers of all affected plug-ins.  But, we're planning such a version change anyway, when we build our plug-ins to target Java 5.  So, this would seem an ideal opportunity to make this kind of change, leaving us in a good position to do versioning correctly in the future.  This is our preference.


2. Ignore the rule and treat re-exported plug-ins independently


We could pretend that we never started re-exporting plug-ins in the first place, and just increment plug-in versions based only on their own changes.  This would save those who aren't concerned interested in strict per-plug-in versioning from facing newly broken dependencies, and would still communicate something useful, but would not respect the expectations of those who are relying on strict plug-in versioning.


One idea we came up with was a new feature for Equinox: if a new directive could be recognized on Require-Bundle to mean "ignore any of this dependency's re-exports", then we could provide proper plug-in versioning (by not considering re-exported plug-ins) for those who choose to "opt in" by using this directive when they depend on our plug-ins.  Alternatively, it could just be a development-time feature in the Plug-in Manifest Editor.  By enabling it, re-exported plug-ins would be ignored, and people could use the tool to add all their dependencies as explicitly required.


This seems like something that could be generally applicable in situations like ours, where re-exports have been used in the past, resulting in a non-modular set of plug-ins.  However, if this isn't a widely shared problem, or if this idea is viewed as just adding more complexity, then that would seem to support option 1 as the best way to go.


Any input would be greatly appreciated.


Cheers,

Dave


--
Dave Steinberg
Rational Software - IBM Toronto Lab
mailto:davidms@xxxxxxxxxx
_______________________________________________
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
_______________________________________________
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


Back to the top