Hi Minto, Hasan, all, How do we want to proceed on this. We have two incompatible proposals and an inpractical status quo. Do we want to have a vote?
Cheers, Reto On Tue, Aug 19, 2014 at 10:06 PM, Reto Gmür <[email protected]> wrote: > > > > 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 >> >> >
