clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Gmür <>
Subject Versions in release branch and release process.
Date Mon, 07 Jul 2014 15:36:28 GMT
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:
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.

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.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message