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