Bug 310927

Comment 1 Matthias Sohn 2010-05-04 20:26:36 EDT

see result of discussion on the list 
http://dev.eclipse.org/mhonarc/lists/egit-dev/msg01099.html

Comment 2 Matthias Sohn 2010-06-15 11:59:34 EDT

We should re-discuss that for the next release in the light of the comments given on bug 316717.

Comment 3 Joakim Erdfelt 2010-09-01 12:08:00 EDT

I've been asked to throw some suggestions in here.

Since you use Maven, you might want to consider adding some enforcer rules to make sure that whatever version string anyone decides on using will conform to some specific set of rules.

Here's the rules we use in Eclipse Jetty.

http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/jetty-toolchain/trunk/jetty-build-support/src/main/java/org/eclipse/jetty/toolchain/enforcer/rules/

You can find their use in the parent pom file here:

http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/jetty/trunk/pom.xml

(snip)
      <!-- Enforcer Plugin --> 
      <plugin> 
        <groupId>org.apache.maven.plugins</groupId> 
        <artifactId>maven-enforcer-plugin</artifactId> 
        <version>1.0-alpha-4</version> 
        <executions> 
          <execution> 
            <id>enforce-java</id> 
            <goals> 
              <goal>enforce</goal> 
            </goals> 
            <configuration> 
              <rules> 
                <requireMavenVersion> 
                  <version>[2.0.6,)</version> 
                </requireMavenVersion> 
                <requireJavaVersion> 
                  <version>[1.5,)</version> 
                </requireJavaVersion> 
                <versionTxtRule implementation="org.eclipse.jetty.toolchain.enforcer.rules.VersionTxtRule" /> 
                <versionOsgiRule implementation="org.eclipse.jetty.toolchain.enforcer.rules.RequireOsgiCompatibleVersionRule" /> 
                <versionRedhatRule implementation="org.eclipse.jetty.toolchain.enforcer.rules.RequireRedhatCompatibleVersionRule" /> 
                <versionDebianRule implementation="org.eclipse.jetty.toolchain.enforcer.rules.RequireDebianCompatibleVersionRule" /> 
              </rules> 
            </configuration> 
          </execution> 
        </executions> 
        <dependencies> 
           <dependency> 
             <groupId>org.eclipse.jetty.toolchain</groupId> 
             <artifactId>jetty-build-support</artifactId> 
             <version>${build-support-version}</version> 
           </dependency> 
        </dependencies> 
      </plugin> 
(/snip)

FYI: According to the OSGi spec, a 3-part version ID is allowed, as long as all 3 parts are non-negative integers.

Comment 4 David Carver 2010-09-01 12:42:23 EDT

Correct a for part version number which the above report was mentioning is actually a qualifier.  In maven 3/tycho this gets generated and created with the .qualifier and is equivalent to the -SNAPSHOT.

An example would be something generated as

org.eclipse.wst.xsl.ui.1.1.0.20100418.jar

For an update site.  The date is generate because of the .qualifier from the manifest.

Comment 5 Matthias Sohn 2011-06-02 20:48:42 EDT

So far we used 4 digit version numbers during development and 3 digit
version numbers for releases. We manually increased the 3. part of the
version number immediately before and after a release was tagged.

We now switched to 4 part version numbers using the following versioning
scheme:

During development we use (this is unchanged to the previously used
versioning scheme)
- 1.2.3-SNAPSHOT for maven artifacts
- 1.2.3.qualifier for OSGi artifacts
-SNAPSHOT and qualifier are expanded to a timestamp at build time

For release candidates and releases we use
- 1.2.3.<timestamp>-rc1 for release candidates
- 1.2.3.<timestamp>-r     for releases

<timestamp> is in timezone of hudson.eclipse.org in the format
"yyyymmddhhmm", e.g. 201106011226

This ensures that newer builds always get a higher version number in both
Maven and OSGi versioning schemes. In addition there is no immediate need
any longer to flip the 3rd part of the version number before and after release 
candidates or releases have been tagged since subsequent nightly builds will 
have higher version numbers due to the increasing timestamp in the 
forth part of the version number.