Hi all, Unfortunately I had some troubles with the release plugin so the versions in the release branch are at the release version rather than at the SNAPSHOT version.
I don't see an easy way to update all release versions to the next snapshot, I've asked for help here: http://stackoverflow.com/questions/24588577/change-to-next-snanpshot-version-in-all-modules-of-multi-module-project/24588891#24588891 However, we could solve the concrete problem (updating to SNAPSHOT) by changing all module versions to 1.0.0-SNAPSHOT. This would allow for semantic versioning, i.e updated not changing the API increase the patch version (making it 1.0.1), update changing the API but maintaining compatibility (this is a bit fuzzy) increase the minor version (i.e. 1.1.0) and updates breaking compatibility would increase the major version (i.e. 2.0.0). Independently of this question I think we should re-discus the release process. I consider the release process as it is now as problematic for the following reasons: 1. When releasing a module we can either release all dependent modules as well or move the dependencies back to the last released version. With the first approach we end up releasing modules that did not change, with the latter we have to make sure that there was indeed no relevant change in the module or in any other module reached via this dependency. 2. When releasing multiple modules, those modules that are not part of the release have to be removed from reactor and deleted in the release branch, otherwise they will be part of the source-zip. As after the release we want to merge back the changes to the version number to master, we have to do a complicated selective merge as we don’t want to merge back the removal of modules nor the downgrading of dependencies. We should change our release process so that: - Releasing is easy and straight forward - We release more often To avoid the first problem with the release process we could depend on released versions instead of SNAPSHOT versions. This would shift the responsibility to update dependencies to the master branch. There we could opt for different policies: A. When any change to a module is made, all dependent modules must be updated. I.e. they have to be changed to depend on the SNAPSHOT version and of course the code has to be modified to work against the changed API. B. Like A but only for incompatible changes C. Dependent modules may be updated but there is no obligation to do so. However when the update of the dependent modules can be done automatically (IDE refactoring feature) developers are encouraged to do so. Variant A is the closes to what we have. When the whole reactor is built every module depends on the version in the reactor, the novelty is that when there was no change since the last release it depends on the released version. The same applies to the launchers which always run the latest code. Variant B relaxes things a bit, for compatible changes there’s no need to update all dependencies. For example if a method is made more performant there is no need to compile the dependent project against the new version, it should only be part of the launchers. Similarly when a new method is added, modules that don’t need the new method can safely be compiled against the previous version. Variant C imposes no obligation on updating dependencies. If one want to show how things become better thanks to the API change she is free to update launchers and other dependent modules. When a dependent module will it reworked in future it will likely be update to the newest versions, like this is done for external dependencies. To address the second problem we could: a. Release modules only individually b. Prepare modules individually for release but call only for one vote on different artifacts c. Have all the modules be individual git repositories. The reactor would include the modules as git modules. For a release a new reactor project with the selected modules is created. With (a) the process of release is significantly delayed as we would only vote on dependent projects once the dependency is released, the vote could be parallelized only for dependencies that do not depend on each other. More useful seems to be the variant (b). The modules are all prepared for release as if the other modules were already released and then a vote is launched for all the modules. Using the current git structure one could use the maven release plugin in every module. A disadvantage is that the SCM tag for each module-release effectively points to the whole source code and not specifically to what the module to be released. To try out a release candidate one has to compile the contents of the source-zips in the right order. For variant (c) we would need to have a platform like gitlab or github so that we can easily create new repositories without requiring INFRA to create a repo for all of our more than 100 modules as well as for every release candidate. If we have such a splitting into many git repository we could also allow both strategy (b) and (c), essentially it doesn’t matter if one presents a vote on a couple of ZIPs individually created from their respective repositories or if a combined ZIP is created using a reactor. I tend to favor the variant with no obligation to update dependent projects (C) and with many small git repositories (c). I think this is the one which most encourages people to participate and submit improvements. People can contribute to the area in which they are most proficient, they no longer need to compile everything. We should release very often, so that depending on SNAPSHOT version is seldom. Launchers are project assembling together a useful set of features. The need for new comprehensive launchers will push modules to depend on the latest versions of other modules. A temporary “schism” might happen, for example if the RDF modules have been updated but the shell (which currently somehow indirectly depends on the RDF stuff) has not: in such a situation we might have a shell launcher which still uses the old RDF bundles and Linked Data launcher with the new RDF features but without shell. WDYT? Reto
