Versioning of OpenJDK forests

[Andrew John Hughes]

2010/1/7 Kelly O'Hair <Kelly.Ohair at sun.com>:
>
> Andrew John Hughes wrote:
>>
>> In testing OpenJDK6 prior to the release of b18, one issue that has
>> arisen is that the version output:
>>
>> openjdk version "1.6.0-internal"
>> OpenJDK Runtime Environment (build
>> 1.6.0-internal-andrew_21_dec_2009_18_36-b00)
>> OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
>>
>> gives no indication as to what hg revisions were used (of which there
>> are 7, there being no whole forest id).
>>
>> I'm thinking something like:
>>
>> openjdk version "1.6.0-internal"
>> OpenJDK Runtime Environment (build
>> 1.6.0-internal-andrew_21_dec_2009_18_36-b00:r<jdk rev id>)
>> OpenJDK 64-Bit Server VM (build 14.0-b16:r<hotspot rev id>, mixed mode)
>>
>> might be helpful in diagnosing regressions between build drops.
>>
>> Has there been any attempt to report repository versions at Sun,
>> either with hg or SCCS?
>
> Well, I've thought about it and filed an RFE:
>  http://bugs.sun.com/view_bug.do?bug_id=6631003
> There are some ideas in that bug report.
>

You seem to be going a bit further than I was envisioning.  I don't
see the need to store the revisions of a build drop as we already have
this encoded by the tag.  If you want b78, you can just do hg fclone
http://hg.openjdk.java.net/jdk7/jdk7

The issue we're seeing is that if you have some arbitrary point after
a build drop, there is no way of determining what changes are present
from the build alone.  I was assuming we'd include the revision ID if
the tree is a hg checkout, but don't really see the need to fake it
otherwise for the tarballs.

> I had hoped to be able to store all the revs in the build image somehow
> so that given any build image, you could re-create a source tree that
> matched it. Tricky with 7 revs. Wish there was a forest revid. :^(

Yeah, we came to that conclusion too on IRC earlier...

> Or maybe a 'java -sourceversion' option to spit it out?

Hmmm... but why is b18 a standard version and the revision ID is just
a source version?  As I see it, a post b18 hg revision is b18+<rev id>

The problem is we don't have the build number anywhere in the tree,
except the tags.  Maybe something llike HotSpot's Makefile that stores
the build number for the JDK is appropriate?  Then you could always
include the current build number and, if it's a hg tree, additionally
include the revision ID.

>
> Also thought it would be nice for developers to just build the source
> tree and get a version string with a build number obtained from the
> tags in the repository, instead of just b00.
> Might need to be something like b78+ if the last changeset wasn't b78's.

Ah yeah that's kind of what I'm saying above.  so the b78 tarball
would produce b78 while a hg checkout would be b78+<rev id>.  The only
issue there is that a checkout of b78 from hg would still include the
revision ID.

> Just ideas...
>
> Never had the time to act on any of this though.
>
> Adding things to the version string can be a little tricky, there's
> some crazy version string parsing logic out there. I would have to
> check with some of the support people to make sure any version string
> changes wouldn't bump into anything they do with it.
>

Yeah, we've come across this.  It's exactly what I was referring to
with JDK_UPDATE_VERSION.  Even Sun's plugin testing applet is guilty
of it.

This is why I envision it as a tool for people building from hg trees
(its primary use being debugging) rather than something present in
packaged builds.

We currently include the revision ID for IcedTea where it's built from hg:

java version "1.7.0_78-icedtea"
OpenJDK Runtime Environment (IcedTea7 1.12-r6cd33d5c844d) (build
1.7.0_78-icedtea-b78)
OpenJDK 64-Bit Server VM (build 17.0-b05, mixed mode)

but the system install gives:

$ java -version
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.6.2) (build 1.6.0_0-b16)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)

> -kto
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8