Versioning of OpenJDK forests

[Kelly O'Hair]

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.

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. :^(
Or maybe a 'java -sourceversion' option to spit it out?

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.
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.

-kto