Re: [eclipse-dev] Talking of version

[Dejan Glozic <dejan@xxxxxxxxxx>]

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