[p4] Changelist number in versions

[Jeff A. Bowles]

This thread doesn't have much activity, yet I wanted to add an additional
two cents.
If "version.h" is autogenerated to fill in the right changenum (and pesky
stuff like "compiler version" and "compiler flags" and "who built it" and
"on which machine, time, etc")...

... then you can have a default "version.h" that developers see and compile
from.

It can include a line that looks like this:
#define     VERS   "2.4-development-line-not-for-distribution"

Then you tell everyone (who might receive a hand-off, like a QA person or
marketing person) that if it mentions "development" in the release string,
to refuse anything that is not labeled as "official".

It keeps things cleaner.

  -Jeff Bowles




On Dec 19, 2007 9:55 AM, Mark Ridgwell <perforce at markridgwell.com> wrote:

> Ivey, William wrote:
> >> You might want to put your output in a different
> >> location that the source, that way, all the builds you do won't
> >> "pollute" your source tree.
> >>
> >
> > That's what we do. It goes under a special include directory that
> > is not under the source tree. (In general, although a given project
> > may have special requirements which just can't be met that way.)
> >
>
> We tend to put the version beside the source tree and update/check that
> in as the 1st step of the build. e.g
>
>     Product\Source\....
>     Product\Versioning\...
>
>  From there we sync the whole source to that point in time, and run a
> few utilities that process the version file and modify the checked in
> source e.g
>
> assemblyinfo.cs -> changes the product version and file versions with
> the ones in verstamp.h.
> *.vbp ->Changes product version etc
> C++ - nothing needed - version information is included in the resources
> and includes verstamp.h to get the information.
>
> There is a lot more in the verstamp.h than just version numbers e.g.
> defines for
>
> Build type -> Internal\External
> Language(s) supported
> Product Name
> Licensing information i.e. which web service to call to request licenses
>
> So it is considered more of an integral part of the build.
>
> Mark
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>



-- 
---
Jeff Bowles - jeff.a.bowles at gmail.com