clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hasan Hasan <>
Subject Re: Versions in release branch and release process.
Date Tue, 15 Jul 2014 04:35:36 GMT
Hi Reto,

On Mon, Jul 7, 2014 at 5:36 PM, Reto Gmür <> wrote:

> 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.
> 2.0.0).

I don't mind changing all module versions to 1.0.0-SNAPSHOT, in particular
if this helps further processing.

> 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.

If I understand correctly, with the first approach we won't have semantic
I don't see problems with the latter approach. Why do we have to make sure
that the modules of the dependency chain have no relevant change?
I think, it is better if we only have last released version in the
dependency chain.
This means in the process of snapsnotizing we may not change versions in the
dependency chain. Is this an issue?

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.

Can we probably do
- selective zip (only those modules which should be part of the release
will be zipped, no removal in release branch except in reactor)
- no merge back to master, but do the step of version number change
directly in master

> We should change our release process so that:
> -    Releasing is easy and straight forward
> -    We release more often

cannot agree more...

> 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.

+1 to all these policies

> 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.

Thanks Reto for this proposal.
I am not sure about Apache policy regarding placing of our code in github
or gitlab.
If someone can check, it is appreciated.
I agree with C and can agree with c if we don't have problem with ASF and
are no costs to bear.


> Reto

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