On Tue, Jul 15, 2014 at 6:35 AM, Hasan Hasan <[email protected]> wrote:
> Hi Reto, > > On Mon, Jul 7, 2014 at 5:36 PM, Reto Gmür <[email protected]> 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: > > > > > 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). > > > > 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 > versioning. > With the first approach we have differnt versions that are actually the same. But the actual semantic versioning happens while the version is a SNAPSHOT version. Say if the code is at 1.0.4-SNAPSHOT and you add new methods you whould change in to 1.1.0-SNAPSHOT, if you make incomüatible changes you would change it to 2.0.0-SNAPSHOT. > 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. > +1 > This means in the process of snapsnotizing we may not change versions in > the > dependency chain. Is this an issue? > Well, yes it can cause issues to. For example you fix a bug in A but then notice that B still shows the issue because it is not depending on the latest version. I think it works well if we relase often and ensure our projects depend on the latest released version (mvn versions:use-latest-versions -Dincludes="org.apache.clerezza:*"). > > 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) > or > - no merge back to master, but do the step of version number change > directly in master > I don't think that there is any tool support for doing this. > > > > > > 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. > > > > Great! > > > > > > 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 > there > are no costs to bear. > I'll ask infra about (c). According with (C) I've merged back the changes into master without updating the dependencies. However for the modules that have not been released the dependencies still need to be updated. I'm struggling with the dependency plugin which refuses to help me: http://markmail.org/message/64e44i2ufowcyl4r :( Cheers, Reto
