Hello Rich,

You can specify build variables, so called properties, in the build engine
as well as the build definition. At least for the command line build i know
that these can be passed to the builder e.g. make. I know ANT builds get
properties passed but am unsure how the situation is with custom properties.
However, my assumption is, if you can use these properties and expand them
into the code today, the mechanism you are using today could be used with
the Jazz build too.

Ralph

Hi all,

We have variables within our code that are were expanded into
meaningful values on our last code repository when extracted (for
example %Z% might be expanded to 1.76, which is the version of that
file).

Is there anyway to do this in Jazz? If not what do people recommend
for keeping track of code levels in the field. The version numbers for
example were usually put into trace, which would help the service team
pinpoint the level of code that they were using, enabling a quicker
turnaround for customer problems (potentially).

Cheers

Rich

Hello Rich,

I have worked with systems that could expand version numbers in files etc.
But I am not aware we have that in RTC.

You would either wait for other comments or ask for a feature to be implemented.
Ideally this would have to be built into the versioning system, otherwise
each change of the version would create a new version of the file, which
would need to be checked in, I guess.

However, I am not sure this feature is really important, I haven't used features
to incorporate the file version into e.g. a header file for many years, but
of yourse this is my personal view. You have the history of the file which
can tell you the version number, you have baselines, snapsots, releases.
e.g. the build number incorporated into a released set of files allows you
to identify the files and pull exactly those file versions from the repository.
Since a file on its own is pretty useless in most cases I know I think it
would be beneficial to create a baseline/snapshot that consistently tags
all files belonging together.

What would be the benefit of having this in the source? Do you ship the source
file rather than some kind of executable? If you think it would be beneficial,
you could create a work item.

Ralph

Hi Ralph,

We previously used CMVC as our code repository and you had two ways to
check out a file, with keywords expanded and with them not expanded.
If you wanted them expanded when you viewed/checked the code out,
then the %Z% would be replaced in each file automatically for you by
CMVC.
As far as I am aware, ant and custom build.properties would not allow
us to do this, or anything similar.

There must be other users of Jazz out there with a similar issue,
multiple versions of code out in the wild, and a service team that
must support multiple versions of the same file. How do they handle
this?

rschoonwrote:

Hello Rich,

You can specify build variables, so called properties, in the build

engine

as well as the build definition. At least for the command line build

i know

that these can be passed to the builder e.g. make. I know ANT builds

get

properties passed but am unsure how the situation is with custom

properties.

However, my assumption is, if you can use these properties and

expand them

into the code today, the mechanism you are using today could be used

with

the Jazz build too.

Ralph