| 1 |
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN2"> |
| 2 |
<html> |
<html> |
| 3 |
<head> |
<head> |
| 4 |
<title>Using Plug-in Versions</title> |
<title>Plug-in Versioning</title> |
| 5 |
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> |
| 6 |
<link rel="stylesheet" href="http://eclipse.org/default_style.css" type="text/css"> |
<meta http-equiv="Content-Style-Type" content="text/css"> |
| 7 |
|
<link href="http://dev.eclipse.org/default_style.css" rel="stylesheet" type="text/css"> |
| 8 |
</head> |
</head> |
| 9 |
|
<body bgcolor="#ffffff"> |
| 10 |
|
|
| 11 |
<body bgcolor="#FFFFFF" text="#000000"> |
<table width="100%"> |
| 12 |
|
<tr><td style="background:#0080C0"><b><span style="color:white">Proposal</span></b></td></tr> |
| 13 |
<h1>Eclipse Plug-in Versioning Proposal</h1> |
</table> |
| 14 |
|
<h1>Eclipse Plug-in Versioning</h1> |
| 15 |
<blockquote> |
<blockquote> |
| 16 |
<p><b>Summary</b> <br> |
<p><b>Summary</b> <br> |
| 17 |
The Eclipse team currently changes their plug-in version numbers to match each |
The Eclipse team currently changes their plug-in version numbers to match each |
| 27 |
and propose a new process for |
and propose a new process for |
| 28 |
using |
using |
| 29 |
plug-in |
plug-in |
| 30 |
version numbering to better indicate levels of compatibility.<br> |
version numbering to better indicate levels of compatibility.</p> |
| 31 |
Last Modified: |
<p>Last Modified: |
| 32 |
1200 February 17, 2004</p> |
November 21, 2004</p> |
| 33 |
</blockquote> |
</blockquote> |
| 34 |
|
|
| 35 |
<h2>Problem Definition</h2> |
<h2>Problem Definition</h2> |
| 36 |
<p>Current Eclipse practice calls for the teams to increment plug-in version numbers |
<p>Current Eclipse practice calls for the teams to increment plug-in version |
| 37 |
to match the upcoming release of Eclipse. For example, about 6 months ago we |
numbers to match the upcoming release of Eclipse. For example, some months |
| 38 |
changed our plug-in version numbers from 2.1 to 3.0.0. In June 2004 we will |
ago we |
| 39 |
ship Eclipse 3.0.0 and all plug-ins (save a few third party ones) will be version |
changed our plug-in version numbers from 3.0.0 to 3.1.0. In May 2005 we will |
| 40 |
3.0.0. This is convenient because it allows people to look at the plug-in version |
ship Eclipse 3.1 and all plug-ins (save a few third party ones) will be version |
| 41 |
|
3.1.0. This is convenient because it allows people to look at the plug-in version |
| 42 |
number and immediatly understand what version of Eclipse that plug-in is from.</p> |
number and immediatly understand what version of Eclipse that plug-in is from.</p> |
| 43 |
<p>This approach has several drawbacks however</p> |
<p>This approach has several drawbacks however</p> |
| 44 |
<ul> |
<ul> |
| 87 |
mechanism for plug-ins. Pushing constraint satisfaction up to the packaging |
mechanism for plug-ins. Pushing constraint satisfaction up to the packaging |
| 88 |
layer puts |
layer puts |
| 89 |
a significant load both on the people creating the packages (e.g., features) |
a significant load both on the people creating the packages (e.g., features) |
| 90 |
as well as the packaging (e.g., feature) mechanism.</li> |
as well as the packaging (e.g., feature) mechanism. And finally, features |
| 91 |
|
are an update mechanism and update is not required to be in a running configuration.</li> |
| 92 |
</ul> |
</ul> |
| 93 |
<h2>Proposal</h2> |
<h2>Proposal</h2> |
| 94 |
<p> To address these concerns, we propose that the Eclipse SDK team start using |
<p> To address these concerns, we propose that the Eclipse SDK team start using |
| 103 |
<ul> |
<ul> |
| 104 |
<li> Immediately after a release, plug-ins continue with the same number as |
<li> Immediately after a release, plug-ins continue with the same number as |
| 105 |
they had in the release (e.g., 1.0.0). </li> |
they had in the release (e.g., 1.0.0). </li> |
| 106 |
<li> As the plug-in is developed for the next release, the version number is |
<li> As the plug-in is developed (whether for a new release or for maintenance), |
| 107 |
changed to accurately reflect those changes. For example, if some minor fixes |
the first three segments of the version number is changed to accurately reflect |
| 108 |
|
those |
| 109 |
|
changes. |
| 110 |
|
For |
| 111 |
|
example, if some |
| 112 |
|
minor |
| 113 |
|
fixes |
| 114 |
are done, |
are done, |
| 115 |
the service (third) segment should be incremented (e.g., 1.0.1). If significant |
the service (third) segment should be incremented (e.g., 1.0.1). If significant |
| 116 |
but compatible rework is done and/or new function added, the minor (second) |
but compatible rework is done and/or new function added, the minor (second) |
| 133 |
1.0.1 still conveys the important information to users of the |
1.0.1 still conveys the important information to users of the |
| 134 |
next |
next |
| 135 |
release. |
release. |
| 136 |
Of course, teams could increment the version further if needed/desired. |
Of course, teams could increment the version further if needed/desired. </li> |
|
Either way, the qualifier (fourth) version segment can be |
|
|
used (e.g., 1.0.1.M3 |
|
|
vs 1.0.1.M5) |
|
|
to differentiate between builds of the same version.</li> |
|
| 137 |
<li> Plug-in version number changes are solely at the discretion of the plug-in |
<li> Plug-in version number changes are solely at the discretion of the plug-in |
| 138 |
development team. They are in the best position to understand their changes |
development team. They are in the best position to understand their changes |
| 139 |
and the scope of impact.</li> |
and the scope of impact.</li> |
| 141 |
version (e.g., 3.0). The org.eclipse.platform 3.0.0 feature contains a complete |
version (e.g., 3.0). The org.eclipse.platform 3.0.0 feature contains a complete |
| 142 |
and precise specification of the plug-ins in the 3.0 platform.</li> |
and precise specification of the plug-ins in the 3.0 platform.</li> |
| 143 |
</ul> |
</ul> |
| 144 |
|
<h3>Use of the qualifier</h3> |
| 145 |
|
<p>The current versioning scheme is effectively highlighting <em> release |
| 146 |
|
families</em>. |
| 147 |
|
A release family is a set of releases which form a substantial and separable |
| 148 |
|
effort. For example, Eclipse 2.0, 2.1, 3.0 and 3.1 are all different release |
| 149 |
|
families. The life of release family continues after its initial release (e.g., |
| 150 |
|
3.0) to include maintenance releases (e.g., 3.0.1, 3.0.2, ...). Using family |
| 151 |
|
numbers as the base for plugin version numbers is convenient and easy to |
| 152 |
|
relate to but, as we have seen, conflicts with the Eclipse |
| 153 |
|
versioning semantics. The proposal outlined above summarily dumps release family |
| 154 |
|
notions |
| 155 |
|
in favour of semantically correct version numbers. This is has its own |
| 156 |
|
problems.</p> |
| 157 |
|
<p>For example, assume we have implemented the proposal above.</p> |
| 158 |
|
<ul> |
| 159 |
|
<li>On June 25, 2004 Eclipse 3.0 is released. org.eclipse.foo is version 1.2.0</li> |
| 160 |
|
<li> The next day a maintenance stream is created in CVS to continue development |
| 161 |
|
for the 3.0.x family of releases.</li> |
| 162 |
|
<li>On June 29, 2004 someone does a minor bug |
| 163 |
|
fix to org.eclipse.foo in HEAD and ups the plugin version number to 1.2.1 |
| 164 |
|
(correctly capturing the nature of the change)</li> |
| 165 |
|
<li>On July 7, 2004 someone does a |
| 166 |
|
different minor bug fix to org.eclipse.foo in the maintenance stream |
| 167 |
|
and ups the plugin version number to 1.2.1 (correctly capturing the nature |
| 168 |
|
of the change)</li> |
| 169 |
|
<li>nothing |
| 170 |
|
else happens to org.eclipse.help before both Eclipse 3.0.1 and Eclipse |
| 171 |
|
3.1 ship.</li> |
| 172 |
|
</ul> |
| 173 |
|
<p>In this case we have to different sets of content for org.eclipse.foo but |
| 174 |
|
the version number is the same. In the current model the plugins would have |
| 175 |
|
version numbers based on their release family and so their intended target |
| 176 |
|
would be clear. The question then is how to mix-in the release family progression |
| 177 |
|
with the plugin content progression. The first three segments of the version |
| 178 |
|
number have clearly |
| 179 |
|
defined semantics which do not match the needs for identifying releases or |
| 180 |
|
release families. The qualifier (fourth segment) however has no particular |
| 181 |
|
semantics and so is free for use.</p> |
| 182 |
|
<p>We propose the use of a convention where the release |
| 183 |
|
family is the first two digits of the qualifier. In the above example this |
| 184 |
|
gives the following version numbers |
| 185 |
|
(respectively)</p> |
| 186 |
|
<blockquote> |
| 187 |
|
<p>1.2.1.31<br> |
| 188 |
|
1.2.1.30</p> |
| 189 |
|
</blockquote> |
| 190 |
|
<p>These are both semantically correct (i.e., numbering indicates the degree |
| 191 |
|
of change) and easily understood as being related to 3.1 and 3.0. This story |
| 192 |
|
is sufficient if we are only concerned about comparing version numbers from |
| 193 |
|
release to release. The other way in which the current (and above) scheme fall |
| 194 |
|
down is that during the development cycle, the version number of a plugin never |
| 195 |
|
changes even though its content may change dramatically. This makes it nearly |
| 196 |
|
impossible for the Update technology to be used successfully on milestone or |
| 197 |
|
integration builds. A refinement to the use of the qualifier resolves this.</p> |
| 198 |
|
<p>Noticing that plugin version numbers are intended to relate to content, the |
| 199 |
|
qualifier should |
| 200 |
|
include the version tag from the map file used for the build. Eclipse is built |
| 201 |
|
by reading a map file which lists a CVS repository location and a version tag |
| 202 |
|
to use when fetching the content. If a team has no input for a build, they |
| 203 |
|
do not update the map file and the version (and thus the plugin) remains unchanged |
| 204 |
|
and identical plug-ins will not be duplicated on the update site and consumers |
| 205 |
|
will not have |
| 206 |
|
to download them if they already |
| 207 |
|
have them.</p> |
| 208 |
|
<p>Using this approach the qualifier looks like <release family>_<tag>. In the |
| 209 |
|
example from above this approach give the following version numbers respectively:</p> |
| 210 |
|
<blockquote> |
| 211 |
|
<p> 1.2.1.31_v20040629<br> |
| 212 |
|
1.2.1.30_v20040707</p> |
| 213 |
|
</blockquote> |
| 214 |
|
<p>This approach gives version numbers which correctly reflect the progression |
| 215 |
|
of the content and respects the release family progression.</p> |
| 216 |
|
<h2>Issues</h2> |
| 217 |
|
<h3>Generating the warm fuzzies</h3> |
| 218 |
|
<p>The main issue that arises from this proposal is that some people |
| 219 |
|
have been getting a warm fuzzy feeling from the current state where plugin |
| 220 |
|
version numbers do "match" the release version number. |
| 221 |
|
Unfortunately this sense of happiness is false. </p> |
| 222 |
|
<ul> |
| 223 |
|
<li> Between releases the plugin contents change but the numbers stay the same. |
| 224 |
|
This apparent matching is only relevant for final GA releases.</li> |
| 225 |
|
<li>Some plugins |
| 226 |
|
(e.g., 3rd party) do not have matching numbers (e.g., lucene) </li> |
| 227 |
|
<li>No warmth |
| 228 |
|
is generated regarding additions or deletions of plugins or features. |
| 229 |
|
Sure they are all numbered nicely but are the right things there?</li> |
| 230 |
|
</ul> |
| 231 |
|
The true warmth generator is a relatively simple tool that checks |
| 232 |
|
the installed set of pluigns/features against a bill of materials generated |
| 233 |
|
as part of the build. The output of this tools shows up in the Configuration |
| 234 |
|
Details |
| 235 |
|
dialog to warm service personel and in the |
| 236 |
|
feature/plugins views of the About dialog to warm users. For example, in the |
| 237 |
|
configuration details, any discrepencies are highlighted while in the About |
| 238 |
|
dialog the matchin is rendered, for example, |
| 239 |
|
as a green check mark beside plugins that match the bill of materials. |
| 240 |
|
<h3>Existing uses of the qualifier</h3> |
| 241 |
|
<p>In some cases we currently use the qualifier to indicate emergency fixes or |
| 242 |
|
patches. Version numbers such as 3.0.1.1 indicate an emergency change made |
| 243 |
|
for 3.0.1 while it was in the field. This proposal does not conflict with that |
| 244 |
|
approach though it does indicate a different approach. 3.0.1.1 as a version |
| 245 |
|
number does generate some warmth as a minor fix to 3.0.1. Under our proposal |
| 246 |
|
the version numbering would look more like:</p> |
| 247 |
|
<blockquote> |
| 248 |
|
<p>1.2.1.30_v20040911 = base version in the 3.0.1 release<br> |
| 249 |
|
1.2.1.30_v20041004 = |
| 250 |
|
patch for the plugin in the 3.0.1 release</p> |
| 251 |
|
</blockquote> |
| 252 |
|
<p>Again, rather than using the version numbers themselves to generate (a somewhat |
| 253 |
|
false) warmth, the simple reporting tool would correctly identify the configuration |
| 254 |
|
as having been patched.</p> |
| 255 |
<h2>Action</h2> |
<h2>Action</h2> |
| 256 |
<p>The only action required is to decide we want to do this and refine/document |
<p>The main action required is to decide we want to do this and refine/document |
| 257 |
the details of the structure and process. There are no technological hurdles. |
the details of the structure and process. PDE build would need some very minor |
| 258 |
Just as teams are responsible updating their copyright dates, they would be |
modifications to accomodate the addition of the release family number but otherwise |
| 259 |
responsible for incrementing their plug-in versions. These changes are done |
there are no technological hurdles. This approach dovetails nicely with a proposal |
| 260 |
very infrequently so will not be a particular burden.</p> |
to enhance Eclipse's use of the update technology. See <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/documents/update.html">Update Site Proposal</a> for more details.</p> |
| 261 |
<p>If we decide to follow this new policy we can retrofit the 3.0 plug-ins with "correct" version |
<p>Going forward teams would be responsible for updating the plugin version just |
| 262 |
|
as they are responsible for updating their |
| 263 |
|
copyright |
| 264 |
|
dates, etc. Note however that these changes are done |
| 265 |
|
very infrequently and will not be a particular burden.</p> |
| 266 |
|
<h3>Transitioning</h3> |
| 267 |
|
<p>If we decide to follow this new policy we can retrofit the 3.1 |
| 268 |
|
plug-ins with "correct" version |
| 269 |
numbers or start the new approach immediately following the release of Eclipes |
numbers or start the new approach immediately following the release of Eclipes |
| 270 |
3.0. Starting now avoids situations where Eclipse 2.1 based plug-ins do not |
3.1. Starting now avoids situations where Eclipse 3.0 based plug-ins do not |
| 271 |
work on the released 3.0 because of resolution problems (rather than because |
work on the released 3.1 because of resolution problems (rather than because |
| 272 |
of actual incompatibilities). However, it may adversely affect people in the |
of actual incompatibilities). However, it may adversely affect people in the |
| 273 |
community who have already come to know, like and use the 3.0.0 version numbers.<br> |
community who have already come to know, like and use the 3.1.0 version numbers.</p> |
| 274 |
</p> |
<p>A concrete proposal for how to do this follows:</p> |
| 275 |
|
<ol> |
| 276 |
|
<li>Assume that the baseline version number is 3.0.0</li> |
| 277 |
|
<li>All teams do a quick review of their plugin changes and update their plugin |
| 278 |
|
version numbers correctly reflect the degree of change since <strong>3.0.0</strong>.</li> |
| 279 |
|
<li>All version numbers are updated to have a ".qualifier" suffix (e.g., 3.0.1.qualifier).</li> |
| 280 |
|
<li>The line "qualifier = context" is added to all build.properties |
| 281 |
|
files</li> |
| 282 |
|
<li>PDE build is setup to add "31_" to the qualifier context for current builds<br> |
| 283 |
|
</li> |
| 284 |
|
</ol> |
| 285 |
</body> |
</body> |
| 286 |
</html> |
</html> |
Parent Directory
| 
Revision Log
| 
Patch