On Sun, Aug 10, 2014 at 11:37 AM, Minto van der Sluis <[email protected]> wrote:
> Reto Gmür schreef op 8-8-2014 14:02: > > On Thu, Aug 7, 2014 at 2:45 PM, Minto van der Sluis <[email protected] > > > > wrote: > > > >> Hi, > >> > >> > >>> 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. > >>> > >> Looking from a user perspective (as using clerezza components). I'd > >> rather like all components to have the same version number. Like this I > >> don't have to think about which component versions work together. I > >> expect all component with the same version to work together well. In my > >> opinion this is option 1. > >> > > No that's not option A ("1" denotes a problem, not an option in my > original > > mail). Option A is that when a module is changed and released all > > /dependent/ modules are released too. Even though I see the benefit from > a > > user perspective, releasing all modules on every change is not an option > in > > my opinion, because: > > - it would unnecessarily float maven central > Depends on how often you intend to release. > > - releases are ideally small as this massively increases changes they get > > properly reviewed > This remains to be seen. Have a look at DataNucleus which is also a > large project. Except for maybe power users it is easier to upgrade a > single version for everything than multiple version for individual > components. > > > http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.datanucleus%22%20AND%20v%3A%224.0.1%22 > Ok, that's 37 artifacts. Clerezza has currently around 200 artifacts. Also I get the impression that the modules therr are more tightly related. Having a global release policy for clerezza means that we have a major update of all rdf modules even if they are actually unchanged but there was an icompatible change with the shell component. > > - it is important for external dependent project to see if the new > versions > > actually change something, an important security fix upstream would > justify > > an new downstream release > This is what release notes are for. > Asking a user of say jaxrs.utils to go through release notes to see if anything changed between version 0.67 and 3.4.2 doesn't seem very user friendly, at least not to the user of jaxrs.utils who doesn't care about rdf, the osgi platform or the shell. > > - we should release often. It is fast and painless to do a release of > > virtuoso.storage after you fixed a bug there. Releasing everything after > > your bug fix in a module is significantly more work, especially if one of > > the modules depends on an external SNAPSHOT version and thus cannot be > > released as it is in the master branch. > Define release often. Is this after a single fix? Or is this after > grouping a number of fixes. Or maybe based on a time schedule. For > instance once a month. The question then remains: When are fixes > important enough to break this schedule? > Pretty much after a single fix. Anything important enough that users can benefit from. So that's pretty much everything but a typo in an error message. Delaying the release in such a case is imho justified only if all of the following are true: - the fix is relatively unimportant (e.g. autocompletions works in some more situations, performance improvement) - some more improvements of that will be completed in the next weeks - there no unreleased improvement in that module oldert than, say 2 month. > > - it doesn't work for the "benign" circular dependecies we have, e.g. the > > pladoc plugin depends on many project that in turn use the plugin, this > > only works by the development version depending on a released version of > > the other. > Seems like there is room for improvement here. ;-) > The circular dependencies cannot be avoided (if you think it can, bring your proposal forward). But I have t admit they aren't an impediment for global versioning. Our maven plugins would simply depend on the latest released version of the modules (while everything else depends on the current (snaphsot) version). Cheers, Reto > > > > > >> I don't mind about unchanged components being rebuild with a newer > >> version. Actually I prefer it like this since it gives me confidence for > >> the reason I gave before (everything with the same version works well > >> together). > >> > > Assuming we have reasonable integration tests this confidence is > justified. > > Now you would have to check in a tested launcher. Things get easier if > you > > use clerezza features as they should provide compatible sets of > artifacts. > > We could also provide an pom-project to be used as scope-import > dependency > > in the dependency-management section providing compatible versions. > > > > > >> To me its one of the first decisions we have to make. > >> [a] Release the whole with a single version number > >> [b] Release individual component with their own version number. > >> > >> I favour option [a]. Also option [a] makes using the maven versions > >> plugin a lot easier. > >> > > The maven release plugin can be used quite easily on a single module. Try > > it out on virtuoso-storage where I think you recently fixed a bug. > > > > Cheers, > > Reto > > > > > >> Who else? > >> > >> Regards, > >> > >> Minto > >> > > > -- > ir. ing. Minto van der Sluis > Software innovator / renovator > Xup BV > > Mobiel: +31 (0) 626 014541 > >
