Re: [eclipse-dev] Talking of version

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

I think you and Pascal are effectively
saying the same thing.  The issue we have right now is we inc'd all
our version numbers to 3.0.0 from 2.1.x.  According to our advertised
versioning semantics, this means the new code is not compatible with 2.1.x.
 As the development team is brutally aware, we are in fact largely
binary compatible with 2.1.  Some plugins did not change at all!  The
fact that we inc'd the version numbers this way is itself a breaking change!

Plugin A's plugin.xml includes
        <import
plugin=org.eclipse.resources" version="2.1">
If you take that plugin and put it in
an Eclipse 3.0 install, it will not even resolve.  Not very compatible.

This is tied in with the parallel discussion
on update sites.  Update sites will only work well if we actually
change the version numbers when the content of a plugin is different.  The
combination of plugin id and version number should uniquely identify a
set of bytes.  That way, the update manager can tell when things have
changed.

In short, 
- plugin developers (whether they are
part of the Eclipse team or not) should inc their version numbers according
to the clearly specified version numbering semantics.  
- the build mechanism should be improved
to tag plugins with a build qualifier.  One candidate is the version
tag used in CVS for the plugin project's map entry.  That way it only
changes if the content changed.

Jeff

Dejan Glozic/Toronto/IBM@IBMCA
Sent by: eclipse-dev-admin@xxxxxxxxxxx

02/12/2004 03:43 PM

Please respond to
eclipse-dev

To	eclipse-dev@xxxxxxxxxxx
cc	eclipse-dev@xxxxxxxxxxx, eclipse-dev-admin@xxxxxxxxxxx
Subject	Re: [eclipse-dev] Talking of version

Incrementing version if there are breaking changes only makes the
versioning as such unpredictable and unreliable. Versioning is very simple:
every time you change something in the release, you increment the version.
Whether you will increment major, minor or service number depends on the
scale of change and compatibility commitments.

In your example, it is not the version that is a problem - it is the
prerequisite. Every plug-in can choose the version 'wiggle space' it is
comfortable in. Typically, plug-ins cannot claim that they will work when
prerequisites increment major release number. That is why 'match' is
'compatible' by default (i.e. minor and service increments). A choice
'greaterOrEqual' would handle this case, but it is hard to make such a
bold
claim.

Regards,

Dejan Glozic, Ph.D.
Manager, Eclipse Development 1A
D2/R0Q/8200/MKM
IBM Canada Ltd.
Tel. 905 413-2745  T/L 969-2745
Fax. 905 413-4854



                    
                     
                     
          
             Pascal      
                     
                     
     
             Rapicault/Ottawa/    
                     
                  
             IBM@IBMCA      
                     
                     To
             Sent by:      
           eclipse-dev@xxxxxxxxxxx  
          
             eclipse-dev-admin    
                     
               cc 
             @eclipse.org      
                     
                     
                    
                     
                     
  Subject 
                    
                  [eclipse-dev]
Talking of version    
             02/12/2004 12:45    
                     
                   
             PM        
                     
                     
       
                    
                     
                     
          
                    
                     
                     
          
             Please respond to    
                     
                  
                eclipse-dev  
                     
                     
 
                    
                     
                     
          
                    
                     
                     
          





Since its inception, eclipse plugin version scheme followed a unified
pattern regardless of API evolution. This leds to some strange situation
where plugins created during eclipse 3.0 development are versionned as
3.0
(see osgi, text buffers, variables...) whereas they are only in version
1.0.

What does this mean: every time the platform change its major, the change
percolates up into the stack forcing many plugins to by repackaged causing
disruption of service. In contrary, if version numbers where used carefully
(increment the major only if there is actual breaking changes), changing
major version would occur less often. This would help in minimizing
perturbation, and as changes go higher in the stack they would attenuate.

Moreover, although we made a goof job of the backward compatibility, any
2.1
plugin that could be backward compatible has to change its plugin.xml if
a
version number has been specified in the prerequisites.

A typical example, when swt changed its number to 3.0 (because eclipse
did
it),
it caused gef to have its prerequisite, causing the absence of a gef build
for
3.0 development.
An aside question is why in this case gef  has to change its version,
whereas
it could silently shelter other plugins from some modifications.

As we move forward post 3.0, it could be interesting to reconsider the
use
of version numbers in the platform and understand if this could help in
avoiding the plugin hell, or if in contrary this would make management
of
the platform and products harder.

What are the repercution on the feature model?

Note that adopting such a version scheme would not prevent us from calling
platform 3.0


        PaScaL

_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
http://dev.eclipse.org/mailman/listinfo/eclipse-dev