I've a strange scenario where I have a project "Y" and it has a module "X" and some other modules as well.

X is part of a project Y however it is not linked as a module of that project. Because of that, each time a newer version of Y is released someone needs to manually update the parent version in X.

I need to update the Y project in such a way that: a)each time the Y project is released, the parent project version in X should be automatically updated by TeamCity (in a similar way as for other modules)

b)X must not be a part of Y distribution

c)Once deployed in TeamCity, it should not run tests from X (they should be run with Integration tests and Release builds)

versions:update-parent

If you open a terminal at the root of your project X, you can use versions:update-parent to update its parent version to the latest:

$ mvn versions:update-parent -DallowSnapshots=true

You can execute this command from TeamCity and then commit the changes to the pom. This can certainly be triggered when Y is built, you could even provide the version (it must be a list or a range):

$ mvn versions:update-parent -DparentVersion=[1.0.0,1.0.1]    //or [1.0.0,1.5.0)

Documentation

See versions-maven-plugin's documentation, especially:

versions:update-parent

updates the parent section of a project so that it references the newest available version. For example, if you use a corporate root POM, this goal can be helpful if you need to ensure you are using the latest version of the corporate root POM.

versions:set

can be used to set the project version from the command line.

versions:commit

removes the pom.xml.versionsBackup

versions:update-child-modules

updates the parent section of the child modules of a project so the version matches the version of the current project. For example, if you have an aggregator pom that is also the parent for the projects that it aggregates and the children and parent versions get out of sync, this mojo can help fix the versions of the child modules. (Note you may need to invoke Maven with the -N option in order to run this goal if your project is broken so badly that it cannot build because of the version mis-match).