updating TestNG and JUnit for jtreg

Martin Buchholz martinrb at google.com
Wed May 4 21:45:11 UTC 2016


It's true that builds at random revisions are tricky.  It probably
doesn't matter that much when the build number is incremented.  Either
right after or right before a release works - I would do the latter.
It should be very unusual for anyone other than jjg to use a
non-tagged build.  cloudbees tries to do "everything at tip" but
unless there's energetic followup, that will result in a lot of
brokenness.

On Wed, May 4, 2016 at 2:16 PM, Jonathan Gibbons
<jonathan.gibbons at oracle.com> wrote:
>
>
> On 05/04/2016 01:49 PM, Martin Buchholz wrote:
>>
>> Thanks!  I was able to successfully build jtreg4.2-b02.
>>
>> One thing I keep stumbling over is the need to update BUILD_NUMBER in
>> my scripts that build jtreg.
>> The makefiles have BUILD_NUMBER = b00, but that has to be overridden
>> at make time or the jtreg version check will fail later.  It's a nice
>> service to your users to update BUILD_NUMBER in the source code before
>> creating the hg release tag (or abandon build numbers entirely).
>> (OTOH, other openjdk builds have the same problem)
>
>
>
> Good suggestion to update the BUILD_NUMBER.
>
> For my part, it works to use b00 in my dev work, and that bypasses
> the version check, but I agree that is not desirable for general usage.
>
> The question is, when should the number be updated, and what should
> the build number show as, when building an otherwise untagged tip
> of the jtreg repo?
>
> For the cloudbees set up, I was suggesting to use a build number
> derived from the latest jtreg tag (for a tagged build) or b00 for a
> build of tip.   I'm open to other general suggestions for good
> practice, here.
>
> -- Jon


More information about the jtreg-use mailing list