Hi,
what is your preferend solution to include auto-incrementing build numbers into your builds (maybe with the help of some VS function, but I think it has none, so I'm not asking in the windows forum)?
Thank you in advance!
Printable View
Hi,
what is your preferend solution to include auto-incrementing build numbers into your builds (maybe with the help of some VS function, but I think it has none, so I'm not asking in the windows forum)?
Thank you in advance!
Compilation date and time? They are implementation defined macros if my memory serves me right.
I thought about that. It would have the drawback that the same binary can have different build numbers.
After one more coffee I think I know now that even a real build number is not precise enough for my needs, because pressing F7 twice would also give different numbers for the same binary.
I think I'll have to create a tool which parses branch name and revno from bazaar and when creates a header file with that string defined inside
Eh, doesn't bazaar have $Id$ replacement?
I tried but I couldn't find anything about that. The closest thing seems to be something like
combined with the --check-clean flagCode:bzr version-info --custom \
--template="#define VERSION_INFO \"Project 1.2.3 (r{revno})\"\n" \
> version_info.h
Just some disjointed thoughts...Quote:
Originally Posted by pheres
I use Perforce for SCM both at work and home and the changelist number is a good unique identifier for a particular revision of the source tree. The problem is that if you are storing multiple products in the depot then each of these products might have the same build number just because they happened to be built at the same CL. In practice that hasn't caused too many issues.
I think it is beneficial to distinguish between dev builds and prod builds. Dev builds are ad-hoc and might not even possess a meaningful version number although you should have some way of identifying the exact revision ANY build was built from (as I said in Perforce the CL is a good way to do that). However dev builds are often built off trees which haven't been checked in yet so they might not have an assigned CL. In those circumstances it is sometimes useful for each developer to work on their own individual branch so that they feel free to check in before every built, but this increasing merging. Prod builds would automatically roll the build number when built.
For an SCM environment which has no explicit support for global revision identifiers you can keep an explicit BuildDescriptor file and update this at every checkin. The tradeoff is that the build descriptor has to be explicitly locked if you want to maintain a monotonic ordering of build numbers.
In VS, you could add a custom pre-build step which increments the version number in a header file or resource definition file. For UNIX environments you could use a shell script and integrate it as part of the build process.
Another piece of advice -- when you access your version number/build number internally from your code, do it through a function instead of accessing the build number macro directly. This prevents tons of stuff from rebuilding just because the build number header got changed. It also makes it possible to easily hot-patch the version number in the binary which can be useful in a number of circumstances.
In bazaar the depot is called repository and can also contain lot of branches each belonging to one or another product. the good thing is, that the revision number is branch-, not repo specific. committing to one branch doesn't affect the revno of other branches. so this is solved.Quote:
Originally Posted by brewbuck
We're using a very decentral approach, where every developer owns oen or more branches. I maintain a common branch, in which I merge all other branches on feature updates or bug fixes. after stabelizing the common branch is merged into a release branch. the revisions inside the release branch are then tagged as version and shipped. so dev andf prod builds are always very apart from each other.Quote:
I think it is beneficial to distinguish between dev builds and prod builds. Dev builds are ad-hoc and might not even possess a meaningful version number although you should have some way of identifying the exact revision ANY build was built from (as I said in Perforce the CL is a good way to do that). However dev builds are often built off trees which haven't been checked in yet so they might not have an assigned CL. In those circumstances it is sometimes useful for each developer to work on their own individual branch so that they feel free to check in before every built, but this increasing merging. Prod builds would automatically roll the build number when built.
Yes, that's exactly what I plan to do.Quote:
In VS, you could add a custom pre-build step which increments the version number in a header file or resource definition file. For UNIX environments you could use a shell script and integrate it as part of the build process.
Thanks, I'll definitely follow this one.Quote:
Another piece of advice -- when you access your version number/build number internally from your code, do it through a function instead of accessing the build number macro directly. This prevents tons of stuff from rebuilding just because the build number header got changed. It also makes it possible to easily hot-patch the version number in the binary which can be useful in a number of circumstances.