Bug 588

'JoglVersion.getInstance().getImplementationCommit()' would return the unique 
git sha1 value, accurately identifying the build, IF you building:
  [1] - as a jenkins node
  [2] - using the git source repository and having git installed, 
          instead of using a 'source tar ball'.

[1] jenkins-master passes git values as properties to the jenkins-slave
[2] build machine queries the git sha1 value, buildnumber is 'manual'

Our current release model is to identify a release _after_ it's actually build & test.
Then we tag the sources and associate the release/builds.
Hence Version is <major>.<minor>-b<buildnumber>-<date>
and not <major>.<minor>-<sub>



Note: Querying the tags belonging to one sha1 can be done like this:

git-show-tags-of-commit.sh
+++
#! /bin/sh

sha1=$1
shift

git show-ref --tags -d | grep ^$sha1 | sed -e 's,.* refs/tags/,,' -e 's/\^{}//'
+++

JOGL example:
> git-show-tags-of-commit.sh 9ff0b0dafea2a03a915c97eb1513c39c27b6a7ae
v2.0-rc8

GlueGen example:
> git-show-tags-of-commit.sh 4ce601b38ca8418eddbe8cca4d531e6161fae26b
v2.0-rc7
v2.0-rc8

Sven, I understand that would work from the git repository and/or with some additional information. 

In my case, if I get only a .jar without any information regarding the version, I would like, from the Java environment, to be able to retrieve the version number.

Thanks

ping ?

Sylvestre, isn't JoglVersion.getSpecificationVersion() enough for you?

No, I need a method "getJOGLVersion()" which would return the String "2.0rc11"
This methods would have to to work from a standalone jar.

Ok. I suggest to add a method called "getSpecificationDetailedVersion()" or something similar into com.jogamp.common.util.JogampVersion (JoglVersion extends JogampVersion), it would return the detailed version including indications about alpha, beta, release candidate versions. When building JOGL, JOAL and JOCL, the script would use Sven's suggestion to inject the correct tag, the end user wouldn't need to use this command to get this information. Is it ok for you Sylvestre? I'm a bit skeptical about this change as I agree with Sven but I understand this new method would ease your job as a package maintainer. The problem is that a release is tagged after it's built and tested.

A priori, your proposal sounds good!

(In reply to comment #6)
> Ok. I suggest to add a method called "getSpecificationDetailedVersion()" or
> something similar into com.jogamp.common.util.JogampVersion (JoglVersion
> extends JogampVersion), it would return the detailed version including
> indications about alpha, beta, release candidate versions. When building
> JOGL, JOAL and JOCL, the script would use Sven's suggestion to inject the
> correct tag, the end user wouldn't need to use this command to get this
> information. Is it ok for you Sylvestre? I'm a bit skeptical about this
> change as I agree with Sven but I understand this new method would ease your
> job as a package maintainer. The problem is that a release is tagged after
> it's built and tested.

Who sneaks in the version ?

Well, we could do it like the maven folks do it - hardcoded like:
  - 2.0rc12-SNAPSHOT : pre 2.0rc12
  - 2.0rc12 : release of 2.0rc12
  - 2.0rc12-SNAPSHOT

This will also benefit Mark and our maven support.

(In reply to comment #8)
> (In reply to comment #6)
> > Ok. I suggest to add a method called "getSpecificationDetailedVersion()" or
> > something similar into com.jogamp.common.util.JogampVersion (JoglVersion
> > extends JogampVersion), it would return the detailed version including
> > indications about alpha, beta, release candidate versions. When building
> > JOGL, JOAL and JOCL, the script would use Sven's suggestion to inject the
> > correct tag, the end user wouldn't need to use this command to get this
> > information. Is it ok for you Sylvestre? I'm a bit skeptical about this
> > change as I agree with Sven but I understand this new method would ease your
> > job as a package maintainer. The problem is that a release is tagged after
> > it's built and tested.
> 
> Who sneaks in the version ?
> 
> Well, we could do it like the maven folks do it - hardcoded like:
>   - 2.0rc12-SNAPSHOT : pre 2.0rc12
>   - 2.0rc12 : release of 2.0rc12
>   - 2.0rc12-SNAPSHOT
> 
> This will also benefit Mark and our maven support.

.. and SNAPSHOT is replaced with a date like YYYYMMDDDD at build time.

this version tag, as Julien mentioned, can be added to the manifest as another special field,
exposed w/ out version class.

Main entry: GlueGen a3f2ef50ad33c58a240a17fcf03e415d772207c3

Adding jogamp.version property, i.e. 2.0.2-rc-<TIMESTAMP> used for Manifest 
Common jogamp_int_version for Android.

Until 2.0.2 gets released, the version string is 2.0.2-rc-<TIMESTAMP>
and used in the Manifest for IMPLEMENTATION_VERSION.

The previous build version name of IMPLEMENTATION_VERSION
goes into the new tag IMPLEMENTATION_BUILD.

Further more, we use a common jogamp_int_version for Android, to make life more easy.

Hence use [Jogamp|Jogl|*]Version.getImplementationVersion()
to get the 'human readable' version string.

Excellent! Many thanks :)

Maybe I am doing something wrong bug the following code

import com.jogamp.opengl.JoglVersion;
public class foo {

    public foo() {
        JoglVersion j = JoglVersion.getInstance();
        System.out.println(j.getImplementationVersion());
    }

    public static void main(String []args) {
        foo f = new foo();

    }

}
returns:
2.0-bmanual-20130516

While I was expecting 2.0-rc12.

Am I missing something ?
Thanks

Looks at:
<https://jogamp.org/deployment/jogamp-current/jogl-applet-version-napplet.html>

..
Implementation Version: 2.0.2-rc12
..

The version was set in git, but post RC12 we removed the [pre-]release tag,
similar to what folks do w/ maven snapshots.

Also, 'bmanual' means that your build was performed manual and not by jenkins.

(In reply to comment #13)
> Looks at:
> <https://jogamp.org/deployment/jogamp-current/jogl-applet-version-napplet.
> html>
> 
> ..
> Implementation Version: 2.0.2-rc12
> ..
> 
> The version was set in git, but post RC12 we removed the [pre-]release tag,
> similar to what folks do w/ maven snapshots.
> 

Following commit 'rows' back to developer version:
<http://jogamp.org/git/?p=gluegen.git;a=commitdiff;h=64dcc55a0aadee4ef824cc145e936cd7bc3c1bdd>


> Also, 'bmanual' means that your build was performed manual and not by
> jenkins.

(In reply to comment #12)
> Maybe I am doing something wrong bug the following code
> 
> import com.jogamp.opengl.JoglVersion;
> public class foo {
> 
>     public foo() {
>         JoglVersion j = JoglVersion.getInstance();
>         System.out.println(j.getImplementationVersion());
>     }
> 
>     public static void main(String []args) {
>         foo f = new foo();
> 
>     }
> 
> }
> returns:
> 2.0-bmanual-20130516
> 
> While I was expecting 2.0-rc12

        JoglVersion j = JoglVersion.getInstance();
        System.out.println("Implementation-Version: "+j.getImplementationVersion());
        System.out.println("Implementation-Build: "+j.getImplementationBuild());
        System.out.println("Implementation-Branch: "+j.getImplementationBranch());

Implementation-Version: 2.0.2-rc-20130710
Implementation-Build: 2.0-bmanual-20130710
Implementation-Branch: master