Upgrade Notes

This page covers:

Changes from 3.1.2 to 4.0

Initial startup time
On the very first start of the new version of TeamCity, the database structure will be upgraded. This process can increase the time of the server startup. The first startup can take up to 20 minutes more then regular one. This time depends on the size of your builds history, average number of tests in a build and the server hardware.

Users re-login will be forced after upgrade
Upon upgrade, all users will be automatically logged off and will need to re-login in their browsers to TeamCity web UI. After the first login since upgrade, Remember me functionality will work as usual.

Previous IntelliJ IDEA versions support
IntelliJ IDEA plugin in this release is no longer compatible with IntelliJ IDEA 6.x versions. Supported IDEA versions are 7.0.3 and 8.0.

Using VCS revisions in the build
build.vcs.number.N system properties are replaced with build.vcs.number.<escaped VCS root name> properties (or just build.vcs.number if there is only one root). If you used the properties in the build script you should update the usages manually or switch compatibility mode on. References to the properties in the build configuration settings are updated automatically. Corresponding environment variable has been affected too.
Read more.

Test suite
Due to the fact that TeamCity started to handle tests suites, the tests with suite name defined will be treated as new tests (thus, test history can start from scratch for these tests.)

Artifact dependency pattern
Artifact dependencies patterns now support Ant-like wildcards.
If you relied on "*" pattern to match directory names, please adjust your pattern to use "**/*" instead of single "*".
If you relied on the "*" pattern to download only the files without extension, please update your pattern to use "*." for that.

Downloading of artifacts with help of Ivy

If you downloaded artifacts from the build scripts (like Ant build.xml) with help of Ivy tasks you should modify your ivyconf.xml file and remove all statuses from there except "integration". You can take the ivyconf.xml file from the following page as reference: http://www.jetbrains.net/confluence/display/TCD4/Configuring+Dependencies

Changes from 3.1.1 to 3.1.2

No noteworthy changes.

Changes from 3.1 to 3.1.1

No noteworthy changes.

Changes from 3.0.1 to 3.1

Guest User and Agent Details

Starting from version 3.1, the Guest user does not have access to the agent details page. This has been done to reduce exposing potentially sensitive information regarding the agents' environment. In the Enterprise Edition, the Guest user's roles can be edited to provide the needed level of permission.

StarTeam Support

Working Folders in Use

Since version 3.1 when checking out files from a StarTeam repository TeamCity builds directory structure on the base of the working folder names, not just folder names as it was in earlier versions. So if you are satisfied with the way TeamCity worked with StarTeam folders in version 3.0, ensure the working folders' names are equal to the corresponding folder names (which is so by default).

Also note, that although StarTeam allows using absolute paths as working folders, TeamCity supports relative paths only and doesn't detect absolute paths presence. So be careful and review your configuration.

StarTeam URL Parser Fixed

In version 3.0 a user must have followed a wrong URL scheme. It was like starteam://server:49201/project/view/rootFolder/subfolder/... and didn't work when user tried to refer a non-default view. In version 3.1 the native StarTeam URL parser is utilized. This means you now don't have to specify the root folder in the URL, and the previous example should look like starteam://server:49201/project/view/subfolder/...

Changes from 3.0 to 3.0.1

Linux Agent Upgrade

• Due to an issue with Agent upgrade under Linux, Agent auxiliary Launcher processes may have been left running after agent upgrades. Versions 3.0.1 and up fix the issue. To get rid of the stale running processes, after automatic agent upgrade, please stop the agent (via agent.sh kill command) and kill any running java jetbrains.buildServer.agent.Launcher processes and start the agent again.

Changes from 2.x to 3.0

Incompatible changes

Please note that TeamCity 3.0 introduces several changes incompatible with TeamCity 2.x:

• build.working.dir system property is renamed to teamcity.build.checkoutDir. If you use the property in you build scripts, please update the scripts.
• runAll.bat script now accepts a required parameter: start to start server and agent, stop to stop server and agent.
• Under Windows, agent.bat script now accepts a required parameter: start to start agent, stop to stop agent. Note that in this case agent will be stopped only after it becomes idle (no builds are run). To force immediate agent stopping, use agent.bat stop force command that is available under both Windows and Linux (agent.sh stop force). Under Linux you can also use agent.sh stop kill command to stop agents not responding to agent.sh stop force.

Build working directory

Since TeamCity 3.0 introduces ability to configure VCS roots on per-Build Configuration basis, rather then per-Project, the default directory in which build configuration sources are checked out on agent now has generated name. If you need to know the directory used by a build configuration, you can refer to <agent home>/work/directory.map file which lists build configurations with the directory used by them. See also Build Checkout Directory

User Roles when upgrading from TeamCity 1.x/2.x/3.x Professional to 3.x Enterprise

When upgrading from TeamCity 1.x/2.x/3.x Professional to 3.x Enterprise for the first time TeamCity's accounts will be assigned the following roles by default:

• Administrators become System Administrators
• Users become Project Developers for all of the projects
• The Guest account is able to view all of the project
• Default user roles are set to Project Developer for all of the projects

See Also:

• Licensing Policy
• Editions