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


Just to be really clear, in your example, are B and C re-exporting A and B (respectively)?  If they are then this seems reasonable.  If they are not then I disagree.

Jeff



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

10/23/2006 11:18 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






I agree with this.  If A changes version, but still falls within the range originally exported by B, then there is no need for B to update its own version number.  However, if B changes the range that it imports for A, then it must increase its own version number accordingly.  Example:


Plugin A version 3.2

Plugin B version 3.2, requires A [3.2,4.0)

Plugin C version 3.2, requires B [3.2,4.0)


If plugin A changes to 3.3, no change is required in B or C.  If plugin B uses new 3.3 API from A, it must update its range to [3.3,4.0), and at that point increase its minor version to 3.3. I.e., the range exported by a plugin is API, and changing that range constitutes an API change by that plugin. That raises the question about what kind of changes B is allowed to make to its import range for A. Clearly B cannot change its import of A to [1.0,2.0) or [3.2,5.0) without breaking C. I think anything other than a minor segment increase to either bound must be seen as a breaking API change.


If this makes sense to everyone I'll update the guidelines accordingly.  Unfortunately this does make the guidelines for re-exported plugins a bit more complicated, which is another argument for avoiding re-exports if possible.


John



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

22/10/2006 08:54 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








Randy,


Your point that by importing a range for A into B and then exporting A, one is effectively exporting a range of A possibilities from B is an extremely good one.  Anything within that range should be expected by any C importing B.   Only by importing A directly into C with a different range, is C entitled to have a different expectation.  As such, any change in A that remains within the range imported by B does not affect what B has declared in terms of expectations on A and should not require B itself to change its own version number nor even its range for A.   So I agree that the rules appear to be broken and as such taking option 2 seems more than reasonable, i.e., ignore the rule and don't change a thing, thereby having no impact on clients, who are of course perfectly free to define more specific import constraints now or in the future.


Clearly it would be nice if the rules were reworded to reflect this thinking so we can say we are closely following the rules.   I'm a strong advocate for following rules, but only as long it, suits me, err, I mean as long at that leads to sensible behavior. ;-)



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



Randy Hudson <hudsonr@xxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

10/20/2006 10:57 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









I think the guidelines are broken.  If plugin B requires plugin A, and in a
given development cycle, B's "stream" is never opened and doesn't even
require maintenance, clients can't expect its version to increment just
because A incremented its minor.  In fact, isn't this what we are saying
when we say B requires A [3.2.0,4.0.0)?  B is not just exporting A, it is
exporting A[3.2.0,4.0.0). If you are C (depends on B) and you don't like
this, you need to restate/restrict your dependency on A. So, it seems like
the problem might be with what C is assuming, not what B has declared. +1
for option 2.

Re-exporting has more than just version issues.  The other scenario is when
you require a large plugin/dependency that is then later broken out into
multiple plugins.  If you weren't exporting that dependency, you could
reduce your dependencies.  Does RCP ring any bells here?

-Randy



                                                                       
          Ed Merks                                                      
          <merks@xxxxxxxxxx                                            
          >                                                          To
          Sent by:                  Cross project issues                
          cross-project-iss         <cross-project-issues-dev@eclipse.o
          ues-dev-bounces@e         rg>                                
          clipse.org                                                 cc
                                                                       
                                                                Subject
          10/20/2006 07:02          Re: [cross-project-issues-dev] EMF  
          AM                        Plug-in Versioning and Reexported  
                                    Dependencies                        
                                                                       
          Please respond to                                            
            Cross project                                              
               issues                                                  
          <cross-project-is                                            
          sues-dev@eclipse.                                            
                org>                                                    
                                                                       
                                                                       





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:                                                               To
cross-project-issues-dev-bou        Cross project issues                  
nces@xxxxxxxxxxx                    <cross-project-issues-dev@xxxxxxxxxxx
                                  >                                    
                                                                     cc
10/19/2006 11:01 PM                 emf-dev@xxxxxxxxxxx                  
                                                                Subject
                                  Re: [cross-project-issues-dev] EMF    
    Please respond to             Plug-in Versioning and Reexported    
  Cross project issues            Dependencies                          
<cross-project-issues-dev@e                                              
       clipse.org>                                                      
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       






> 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-boun                                          To
ces@xxxxxxxxxxx                      cross-project-issues-dev@xxxxxxxxxxx
                                                                     cc
                                   emf-dev@xxxxxxxxxxx                  
10/18/2006 11:19 AM                                               Subject
                                   [cross-project-issues-dev] EMF      
                                   Plug-in Versioning and Reexported    
    Please respond to              Dependencies                        
   Cross project issues                                                
<cross-project-issues-dev@ec                                            
        lipse.org>                                                      
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       







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@xxxxxx.com_______________________________________________
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
_______________________________________________
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