I am currently implementing (I do not know if implementing is the appropriate word, but anyway) a semantic versioning in TeamCity. I have project level system parameters in which I store version number parts: system.major, system.minor, and system.patch. I have two build configurations:
- First, we call it beta, is using the major, minor, and patch as-is and appends its build counter value to the version (i.e 1.0.0.X where X is beta's build count).
- Second, we call it release, is using the major, and minor (but not patch) as-is and appends its build counter value as patch number (i.e 1.0.Y where Y is release's build count).
We want our versions to increment like following:
- A beta build is run: 1.0.0.1
- Another beta build: 1.0.0.2
- A release build is run: 1.0.1.0
- Yet another beta build: 1.0.1.3
The problem is, we want to use the release build's counter as patch number in beta build as well, without any human intervention. So far, I have read about people using assembly info or external VCS-tracked file to store the current version in last build step and parse the file in the first build step of every build configuration. This approach, though appears to be the standard way, is not welcomed by the project's manager, so I want to avoid using assembly info or another VCS-tracked file to store the version info. I have tried to use a powershell script build step in release configuration to set the parameter patch using:
Write-Host "##teamcity[setParameter name='system.patch' value='%build.counter%']"
yet, using teamcity[setParameter...] appears to take effect inside the running build and only on consecutive build steps. What I want is to set the system parameters in one build (release) and later, use their value in another build configuration (beta).
Is there any straight-forward way that I fail to see? If you have similar experience, can you point me to the right direction?
