jtreg nightly build version change

[Jonathan Gibbons]

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.gibbons at oracle.com <mailto:jonathan.gibbons at 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
>
>