Build counter and build number format best practice
So I am new to teamcity and I'm looking for best practice regarding the build counter and build number. We have our build number format setup like this: major.minor.build_counter.vcs_revision
Previous to teamcity we would produce 1 build a day and would only increment the build_counter if build succeeded. In teamcity the build counter is incremented even if the build fails.
So since I'm new to teamcity I was looking for best practice to decide if I should use the build counter or a custom variable that will only be incremented when build is successful.
Please sign in to leave a comment.
Hi Carl,
Each company (and sometimes each product even within a company) has their own versioning policy, so that decision should be internal. Versioning rarely has a "best practices", as long as it is meaningful and comprehensive. The build counter is provided because some VCS systems, like for example git, use a hash instead of a counter or comprehensive, incremental number for the revision. With this in mind, the build counter provides an easy way to track build numbers. If you want to not use the build counter at all because your vcs system provides an acceptable versioning scheme, then that's perfectly usable as well.
One of my concern was that if I use a different number than build_counter in my versions it won't be as clear. For example if I'm looking at the field "fixed in build" in YouTrack (I haven't tried YouTrack yet) then the build# in there won't match the version of the software itself. I was looking for advice regarding these kind of "problems".
Hi Carl,
the fixed in build field in youtrack is filled with the build number, not the counter. This is why I mentioned the "meaningful and comprehensive". For example, we in TeamCity add the build where the bug was fixed, even if that build never went out as a production release. Because the number is always incremental, if a given release's build number is larger than the "fixed in build", that means that the issue was fixed for that build, even if the "fixed in build" number doesn't "exist" as a release.
If your numbering allows the users to understand this, it shouldn't be an issue.