Fwd: build # in manifests of our jars

Ian Springer ian.springer at redhat.com
Tue Feb 2 17:02:40 UTC 2010


On 02/02/2010 11:48 AM, Joseph Marques wrote:
> On 02/02/2010 11:39 AM, Jason Dobies wrote:
>    
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Forwarding to rhq-devel
>>
>> - -------- Original Message --------
>> Subject: build # in manifests of our jars
>> Date: Tue, 02 Feb 2010 11:25:24 -0500
>> From: Ian Springer<ian.springer at redhat.com>
>> Organization: Red Hat, Inc.
>>
>> As some of you may know, a Build-Number attribute is written in the
>> manifest of all of our jars. This build # can be found in the GUI by
>> selecting the Help>About menu item or from the Agent by typing the
>> 'version' prompt command. Traditionally, the build # is used most by QE
>> to quickly ascertain what version of the source their build was built from.
>>
>> In our SVN days, the SVN revision was used as the build #, which worked
>> nicely, since SVN revisions are guaranteed to be sequential over time.
>> For example, if I knew RHQ 1.2 was SVN r4000 and RHQ 1.3 was SVN r5000,
>> and my local build had build # 4500, then I know I'm working with a
>> build from somewhere in between 1.2 and 1.3.
>>
>> Since we switched to git, the Build-Number attribute is always 0. This
>> is because the buildnumber plugin we were using only supported SVN. I've
>> updated the linux-config branch to start using the abbreviated git
>> last-commit SHA-1 hash (e.g. 7e45a62) as the build #. This is useful but
>> it lacks the quality of being sequential over time like SVN revisions.
>> To compensate for this, I've also made sure all our jars have a
>> Build-Time header which contains a human-readable date+time string. Does
>> this work for people, particularly QE, or would people prefer the build
>> # to be a sequential integer based on the current time (e.g.
>> year.dayOfYear.secondOfDay or seconds-since-epoch)? Or do people prefer
>> that both are provided, e.g.:
>>
>> Build-Number: 10-33-23012
>>
>>      
> Why not "month/day/year time"?
> _______________________________________________
>    
That's another option, though I'd try to put the most significant 
characters first to make it more version-like, e.g.:

2010/02/02 11:58:02

or even:

20100202115802

which is the format Maven uses in the maven-metadata.xml files found in 
its repos.

For normalization, I think the GMT time zone should be used.

Keep in mind, we will also have the Build-Time header which will have 
the date and time in a nice human-friendly form.

Whatever we decide to go with, it looks like Bugzilla has a "Build ID" 
field we can stick the build # and/or git hash in when creating bugs.



More information about the rhq-devel mailing list