platform-core-home/documents/plugin-versioning.html
Parent Directory
| 
Revision Log
Revision 1.1 - (view) (download) (as text)
| 1 : | jeff | 1.1 | </head> |
| 2 : | |||
| 3 : | <body bgcolor="#FFFFFF" text="#000000"> | ||
| 4 : | |||
| 5 : | <h1>Eclipse Plug-in Versioning Proposal</h1> | ||
| 6 : | <blockquote> | ||
| 7 : | <p><b>Summary</b> <br> | ||
| 8 : | Last Modified: 1100 February 17, 2004</p> | ||
| 9 : | </blockquote> | ||
| 10 : | |||
| 11 : | <h2>Problem Definition</h2> | ||
| 12 : | <p>Current Eclipse practice calls for the teams to increment plugin version numbers | ||
| 13 : | to match the upcoming release of Eclipse. For example, about 6 months ago we | ||
| 14 : | changed our plugin version numbers from 2.1 to 3.0.0. In June 2004 we will | ||
| 15 : | ship Eclipse 3.0.0 and all plugins (save a few third party ones) will be version | ||
| 16 : | 3.0.0. This is convenient because it allows people to look at the plugin version | ||
| 17 : | number and immediatly understand what version of Eclipse that plugin is from.</p> | ||
| 18 : | <p>This approach has several drawbacks however</p> | ||
| 19 : | <ul> | ||
| 20 : | <li>Incrementing the major (first) | ||
| 21 : | version segment renders the plugin "incompatible" with | ||
| 22 : | all previous versions of that plugin. Dependent plugins which specify a version | ||
| 23 : | number (e.g., <import plugin="org.eclipse.foo" version="2.1.0"/>) | ||
| 24 : | will not resolve against version 3.0.0 of the prerequisite plugin. Unresolved | ||
| 25 : | plugins cannot participate in a running Eclipse environment. Even though | ||
| 26 : | we have worked hard to make the content of the 3.0 plugins binary backward | ||
| 27 : | compatible, | ||
| 28 : | 2.1 based third party plugins (which specify prereq version numbers) require | ||
| 29 : | changes to work in 3.0.</li> | ||
| 30 : | <li>This approach does not set a good example. People building on top of | ||
| 31 : | Eclipse look to us to understand how they should structure their world. | ||
| 32 : | Following this | ||
| 33 : | model, plugins like EMF and GEF should increment their version numbers | ||
| 34 : | to match the Eclipse version numbers regardless of whether they changed | ||
| 35 : | at all. This | ||
| 36 : | has the nasty side effect of rendering all of their users incompatible | ||
| 37 : | as well. It also does not scale well as a little change at the bottom then | ||
| 38 : | ripples all | ||
| 39 : | the way up.</li> | ||
| 40 : | <li> Eclipse is getting away with this because a) we are at the bottom of | ||
| 41 : | the stack, b) we ship a single wad that is built, packaged and distributed | ||
| 42 : | in unison | ||
| 43 : | and c) we do not use version numbered prerequisites ourselves. It is | ||
| 44 : | really this last point which hurts the most. By not using versioned prereqs, | ||
| 45 : | we | ||
| 46 : | are not eating our own dog food. Clearly we do not mean that the resources | ||
| 47 : | plugin | ||
| 48 : | from 3.0 will run on ANY version of the Eclipse runtime. People who build | ||
| 49 : | and distribute plugins are not generally able to play it quite so fast | ||
| 50 : | and loose.</li> | ||
| 51 : | <li> Features are not the cure. To address some of this, we use features and | ||
| 52 : | their abilily to group plugins. The assumption is that if the feature | ||
| 53 : | constraints are met, then the underlying plugins will all be happy and thus | ||
| 54 : | versioned | ||
| 55 : | plugin dependencies are not needed. This works but assumes that the feature | ||
| 56 : | writer | ||
| 57 : | (may not be related to the plugin authors) can understand the plugin | ||
| 58 : | constraints well enough to define the feature. In practice this means that | ||
| 59 : | the plugins | ||
| 60 : | in the feature all have similar constraints such that they can be distilled | ||
| 61 : | to a smaller set of inter feature constraints. Features are a packaging | ||
| 62 : | mechanism for plugins. Pushing constraint satisfaction up to the packaging | ||
| 63 : | layer puts | ||
| 64 : | a significant load both on the people creating the packages (e.g., features) | ||
| 65 : | as well as the packaging (e.g., feature) mechanism.</li> | ||
| 66 : | </ul> | ||
| 67 : | <h2>Proposal</h2> | ||
| 68 : | <p> To address these concerns, we propose that the Eclipse SDK team start using | ||
| 69 : | the version number semantics defined by Eclipse for all their plugins. The | ||
| 70 : | numbering process works as follows:- new plugins start as 0.0.0 and go through | ||
| 71 : | various version numbers (<1.0.0) | ||
| 72 : | until they are ready for their first release. At that time, developers may | ||
| 73 : | choose to set the version number to 1.0.0. This is mostly cosmetic and is not | ||
| 74 : | required. Prior to first release the numbering process depends mostly on how | ||
| 75 : | widely availability and use of the early versions. For example, a beta at 0.9 | ||
| 76 : | sets a good tone and might encourage release at 1.0.0. </p> | ||
| 77 : | <ul> | ||
| 78 : | <li> Immediately after a release, plugins continue with the same number as | ||
| 79 : | they had in the release (e.g., 1.0.0). </li> | ||
| 80 : | <li> As the plugin is developed for the next release, the version number is | ||
| 81 : | changed to accurately reflect those changes. For example, if some minor fixes | ||
| 82 : | are done, | ||
| 83 : | the service (third) segment should be incremented (e.g., 1.0.1). If significant | ||
| 84 : | but compatible rework is done and/or new function added, the minor (second) | ||
| 85 : | segment should be incremented. (e.g., 1.1.0). Note that in this example, | ||
| 86 : | the significant work overshadows the service fixes so the service (third) | ||
| 87 : | segment | ||
| 88 : | is set to 0. If major rework is done such that the new version is incompatible | ||
| 89 : | with previous versions then the major (first) segment should be incremented | ||
| 90 : | (e.g., 2.0.0) Note that the minor and service numbers are 0 here as well.</li> | ||
| 91 : | <li> A plugin's version number need only be incremented to distinguish one | ||
| 92 : | release from another. For example, if we release 1.0.0 of a plugin and then | ||
| 93 : | do some | ||
| 94 : | bug fixes for a milestone (say M3), we increment the version to 1.0.1. | ||
| 95 : | If that plugin were eventually released, people could look at the version | ||
| 96 : | number and | ||
| 97 : | see that a) it is different from 1.0.0 and b) that some bug fixes were | ||
| 98 : | done. If instead, further bug fixes are done for M5, there is no need to | ||
| 99 : | further | ||
| 100 : | increment in the version number (i.e., to 1.0.2). Leaving it at 1.0.1 still | ||
| 101 : | conveys the important information to users of the next release. Between | ||
| 102 : | releases the qualifier (fourth) version segment can be used (e.g., 1.0.1.M3 | ||
| 103 : | vs 1.0.1.M5) | ||
| 104 : | to differentiate.</li> | ||
| 105 : | <li> Plugin version number changes are solely at the discretion of the plugin | ||
| 106 : | development team. They are in the best position to understand their changes | ||
| 107 : | and the scope of impact.</li> | ||
| 108 : | <li> Features are used to group together plugins and label them with a particular "product" release | ||
| 109 : | version (e.g., 3.0). The org.eclipse.platform 3.0.0 feature contains a complete | ||
| 110 : | and precise specification of the plugins in the 3.0 platform.</li> | ||
| 111 : | </ul> | ||
| 112 : | <h2>Action</h2> | ||
| 113 : | <p>The only action required is to decide we want to do this and refine/document | ||
| 114 : | the details of the structure and process. There are no technological hurdles. | ||
| 115 : | Just as teams are responsible updating their copyright dates, they would be | ||
| 116 : | responsible for incrementing their plugin versions. These changes are done | ||
| 117 : | very infrequently so will not be a particular burden.</p> | ||
| 118 : | <p>If we decide to follow this new policy we can retrofit the 3.0 plugins with "correct" version | ||
| 119 : | numbers or start the new approach immediately following the release of Eclipes | ||
| 120 : | 3.0. Starting now avoids situations where Eclipse 2.1 based plugins do not | ||
| 121 : | work on the released 3.0 because of resolution problems (rather than because | ||
| 122 : | of actual incompatibilities). However, it may adversely affect people in the | ||
| 123 : | community who have already come to know, like and use the 3.0.0 version numbers.<br> | ||
| 124 : | </p> | ||
| 125 : | </body> | ||
| 126 : | </html> |
| help@eclipse.org | ViewVC Help |
| Powered by ViewVC 1.0.3 |