added a comment - - edited
I believe version ranges in parent POMs should be supported, because they enable an important usage pattern of maven.
I understand the argument for keeping the parent version a fixed quantity. It makes it possible to store the build repository URL in the parent POM, thus eliminating the need for an external settings file. This makes builds self-contained and reproducible.
However, I would argue that this pattern only works well for small maven projects, because it has several implications. First, it implies that whenever the parent POM version is updated, all POMs referencing it must be updated as well with the new version. This greatly reduces the ability to do partial builds, because each time the parent changes all projects referencing it change as well. Second, assuming the parent POM contains the repository URL, it must always be checked out along with the remaining source code. In large multi-module projects developers may only check out the part of the source tree that's relevant to them. Finally, it assumes developers actually update the parent version when they make a change. If they forget to do it, CI builds that perform the deployment will fail, because the parent versions already exist. In large, loosely-coupled development organization such an assumption cannot be made.
Using version ranges in parent references along with the following usage pattern can alleviate this problem:
- store each parent version in a separate repository
- point to the parent repository in the settings file
- whenever going to an older source version, delete cached parent artifact in ./m2
Note that the parent repository URL in the settings file could be derived from the current source version to keep builds reproducible. The process can also be automated to ease the burden on developers. Furthermore, since the parent references specify ranges, the CI system can automatically append a unique (and increasing) qualifier when deploying the parent to eliminate the assumption that developers will update the parent version.
Now it could be argued that in development parent references should use snapshot versions. Apart from the fact that snapshot version have their own issues when it comes to large-scale projects, this argument would be self-contradicting in this context, since snapshots are version ranges of the form "version-[beginning of time, end of time]".