Version Numbering Europa Update
As more projects have begun using the Eclipse project Version Numbering Guidelines, further clarification is required to capture the development processes of different projects. To this end, a number of updates have been made for the Europa Simultaneous Release since the initial guidelines were written. This document describes the changes, along with the motivation for the change.
When to increment the service segment
The initial guidelines stated that the service segment must be incremented when there is a "bug fix". This criterion is unclear, because the kind of change that constitutes a "bug fix" is open to interpretation. For example, is a documentation change or a change to compiler settings considered a bug fix? The answer is yes. The guidelines have been revised to state:
The service segment number must be incremented whenever there have been changes to a plug-in between releases that are not visible in its API. For example, a bug has been fixed in the code, the plug-in manifest has changed, documentation has changed, compiler settings have changed, etc.
In other words, if the bits on disk have changed, then at least your service segment must also change. This guideline ensures that the builds prior to a release can be distinguished from builds made to a maintenance stream after a release. This also ensures that the update manager and OSGi resolver will always correctly pick the version of the plug-in from the most recent release. Relying on the lexigraphical order of the qualifier segment for this task is error prone, since a simple typo when tagging a project for a build could result the wrong version being chosen (for example changing from "v20060601" to "V20060602", or "v20060601" to "I20060602", or "v20051231" to "v20050101", to give just three examples of mistakes that have been made).
Managing multiple maintenance branches
The initial guidelines assumed there would only ever be one maintenance branch under active development at a time, along with one primary development branch, for a total of two branches. This assumption stemmed from the Eclipse project policy of only maintaining one maintenance branch. However, other projects can and do occasionally perform ongoing maintenance in multiple branches. For the most part, the existing guidelines continue to be useful across arbitrary simultaneous branches.
The important extra rule here is to ensure you "leave room" whenever performing maintenance on a branch that is not your oldest maintenance branch. If you have maintenance branches for releases N, N+1, and N+2, the increment by 100 rule applies in the N+1 branch, and you must increment by another 100 in the N+2 branch. This ensures there is room to make changes in the N maintenance branch without overlapping version numbers. This paragraph has been added to the guidelines to clarify this.
Minor version changes in a maintenance branch
The initial guidelines said only this about changing the minor segment of a version number in a maintenance branch:
Such changes would not typically be made when working in a maintenance stream.
This isn't particularly useful for those who have a compelling need to introduce new API in a maintenance branch. This paragraph has been added to the guidelines to clarify how this should be handled.
Correction of feature versioning example
There was an error in the feature versioning example that incorrectly made the org.eclipse.gef feature require the org.eclipse.platform feature:
Case 2: In the new model it should be: requires feature org.eclipse.platform 3.1.0 [removed this line] contains plugins: org.eclipse.draw2d 3.1.0 org.eclipse.gef 3.1.0 requires plugins: org.eclipse.core.runtime [3.1.0, 4.0.0) org.eclipse.ui.views [3.1.0, 4.0.0) org.eclipse.ui.workbench [3.1.0, 4.0.0) org.eclipse.jface [3.1.0, 4.0.0) org.eclipse.swt [3.1.0, 4.0.0)