> @@ -20,8 +20,8 @@ > <project xmlns="http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > <modelVersion>4.0.0</modelVersion> > <parent> > - <groupId>org.apache.jclouds.labs</groupId> > - <artifactId>jclouds-labs-openstack</artifactId> > + <groupId>org.apache.jclouds</groupId> > + <artifactId>jclouds-project</artifactId> > <version>1.7.0-SNAPSHOT</version>
> If I understand what you are saying, when releasing, say, 1.6.3, the > jclouds-version property (now replaced by project.parent.version) > will make the labs projects use 1.6.3 as a dependency @zack-shoylev Sorry, I didn't explain that very well, it seems ;-) With the POM as currently suggested, the _jclouds_ version is not the problem, since a separate property controls that. The problem is the version _of this project itself_. The POM as currently written inherits its version for the parent `jclouds-project` POM, so they must always be in lockstep. So let's consider what happens for the 1.6.3 release. 1. The main jclouds project will be released. That creates a `jclouds-project` POM with version 1.6.3. This labs project will still be a snapshot 2. We then want to release this labs project. Presumably, the 1.6.3 labs project release should depend on `jclouds-project:1.6.3`, so we would have to change that dependency before the release of this project 3. But then _we can't release this project any more because it doesn't have a snapshot version_ - it will immediately inherit the 1.6.3 version from the jclouds-project dependency change in step 2 So the version of _this_ project has to be decoupled from the version of the _parent_ project. And then `jclouds-version` can simply be replaced by the version of the parent project, since it refers to dependencies from the main jclouds project. Does that make more sense? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-openstack/pull/11/files#r4951887
