Martin,
Right now, the latest tag in the repo should be jtreg4.1-b08. It seems
to be it would be good if your build could reflect that. There should be
enough hooks in the build script to allow you to set the version.
-- Jon
On 01/20/2014 09:54 AM, Martijn Verburg wrote:
Hi Jonathan,
Thanks for the info. In that case I'll change the build to produce a
4.2.0-SNAPSHOT following the traditional model. I guess we can then
work on the build script to allow it to produce formal releases (such
as 4.2.0) to Maven central.
I don't have permission to raise an issue directly in JBUG for this,
are you able to or does it still need to go through the bugs.sun...
method?
Cheers,
Martijn
On 20 January 2014 17:47, Jonathan Gibbons
<jonathan.gibb...@oracle.com <mailto:jonathan.gibb...@oracle.com>> wrote:
On 01/18/2014 05:29 AM, Martijn Verburg wrote:
Hi all,
https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/
now produces a Maven compatible 5.0.0-SNAPSHOT version of jtreg.
This was to make the download and install for the Virtual
Machines we're producing for the build-farm as well as making
jtreg Maven repo compatible.
IIRC jtreg was last released as version 4.3? Hopefully 5.0.0
is the next logical number.
Probably needs a conversation about how to deal with
versioning and if jtreg can be uploaded to Maven Central or
not (any legal barriers?).
Cheers,
Martijn
Martijn,
jtreg has never been 4.3. I think you're confusing it with the
version of JTHarness that it uses.
For a while now, jtreg has been using jtreg 4.1 bNN where NN is a
small interger, currently 08. This was more significant when we
(Oracle) were producing binary builds. Now that we are no longer
doing that, I think we will start advancing the jtreg number in a
more conventional fashion.
I had hoped to combine the advance to 4.2 with a major update to
the jtreg documentation, but that seems to be never quite high
enough priority to have anything happen :-(
-- Jon
