| 1 |
|
<html> |
| 2 |
|
<head> |
| 3 |
|
<title>Using Plug-in Versions</title> |
| 4 |
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
| 5 |
|
<link rel="stylesheet" href="http://eclipse.org/default_style.css" type="text/css"> |
| 6 |
</head> |
</head> |
| 7 |
|
|
| 8 |
<body bgcolor="#FFFFFF" text="#000000"> |
<body bgcolor="#FFFFFF" text="#000000"> |
| 10 |
<h1>Eclipse Plug-in Versioning Proposal</h1> |
<h1>Eclipse Plug-in Versioning Proposal</h1> |
| 11 |
<blockquote> |
<blockquote> |
| 12 |
<p><b>Summary</b> <br> |
<p><b>Summary</b> <br> |
| 13 |
Last Modified: 1100 February 17, 2004</p> |
The Eclipse team currently changes their plug-in version numbers to match each |
| 14 |
|
major release of Eclipse (e.g., 2.1, 3.0). This is a convenient |
| 15 |
|
way of understanding the origin of plug-ins but do not capture the actual |
| 16 |
|
semantics of the changes which occurred. For |
| 17 |
|
example, the change from 2.1 to 3.0 indicates a major and incompatible change. |
| 18 |
|
Of |
| 19 |
|
course, this |
| 20 |
|
is |
| 21 |
|
generally not what was intended as most 3.0 plug-ins are in fact compatible |
| 22 |
|
with their 2.1 versions. Here we outline the current use of version numbers |
| 23 |
|
and propose a new process for |
| 24 |
|
using |
| 25 |
|
plug-in |
| 26 |
|
version numbering to better indicate levels of compatibility.<br> |
| 27 |
|
The Eclipse Last Modified: |
| 28 |
|
1200 February 17, 2004</p> |
| 29 |
</blockquote> |
</blockquote> |
| 30 |
|
|
| 31 |
<h2>Problem Definition</h2> |
<h2>Problem Definition</h2> |
| 117 |
see that a) it is different from 1.0.0 and b) that some bug fixes were |
see that a) it is different from 1.0.0 and b) that some bug fixes were |
| 118 |
done. If instead, further bug fixes are done for M5, there is no need to |
done. If instead, further bug fixes are done for M5, there is no need to |
| 119 |
further |
further |
| 120 |
increment in the version number (i.e., to 1.0.2). Leaving it at 1.0.1 still |
increment in the version number (i.e., to 1.0.2). Leaving the version at |
| 121 |
conveys the important information to users of the next release. Between |
1.0.1 still conveys the important information to users of the |
| 122 |
releases the qualifier (fourth) version segment can be used (e.g., 1.0.1.M3 |
next |
| 123 |
|
release. |
| 124 |
|
Of course, teams could increment the version further if needed/desired. |
| 125 |
|
Either way, the qualifier (fourth) version segment can be |
| 126 |
|
used (e.g., 1.0.1.M3 |
| 127 |
vs 1.0.1.M5) |
vs 1.0.1.M5) |
| 128 |
to differentiate.</li> |
to differentiate between builds of the same version.</li> |
| 129 |
<li> Plugin version number changes are solely at the discretion of the plugin |
<li> Plugin version number changes are solely at the discretion of the plugin |
| 130 |
development team. They are in the best position to understand their changes |
development team. They are in the best position to understand their changes |
| 131 |
and the scope of impact.</li> |
and the scope of impact.</li> |
Parent Directory
| 
Revision Log
| 
Patch