The issue we are aiming to resolve here is primarily how to releae multi-module products.

This includes:

Management of Parent Version References

The current thinking on this is that in general the parent version will not be specified in the POM and that it will be located using the current search algorithm:

This prevents the need to make changes consistently to that when the parent increments its version. At the point of release, the version will be populated with what was found at the time to make the build reproducible.

Inheritence of the Version from a Parent

While this was originally planned and executed on continuum and m2, among others, it proves problematic for making a release, and prevents making interim releases of individual components for patches or use in other applications (unless snapshots are used which is not particularly desirable as they haven't been properly promoted).

The planned approach is to:

Implications for Source Control

While making each module independant it has implications for tagging releases, and how checking out from source control works.

Desired outcomes:

Checking out an individual module

This will build on its own since the parent is referenced using a repository location. However, if the version is omitted and RELEASE is assumed, then the behaviour between the search paths above is different (ie, in the reactor or USD you get the latest from your checkout, but when checked out on its own, you get what is in the repository as a release).

I believe this is not a problem, and that the behaviour can be expected. It should encourage proper releasing of the parent when it is changed.

Being able to check out the entire source tree, tags and branches

What this involves is for all projects to have a common root. Obviously if they are being built together with the modules definition then this will be the case. This also means that they need to be tagged together, and uniformly.

The assembly should also be made at the root and incorporate the modules at that point of time, otherwise the dependency versions could well be out of sync with what is tagged in the SCM.

This becomes a problem in subversion if the individual components have a trunk/branches/tags structure due to being tagged or branched separately. It is expected that the lowest point you would check out from will be the trunk/branches/tags, and those below cannot be tagged or branched.