Hi Reto, Minto, all I still favor releasing only modules that have changed instead of the whole clerezza modules. I kindly ask other developers to also give their opinions. If we still have, say by the end of this week, two or more different release procedures we need to vote, I suggest.
Cheers Hasan On Sun, Aug 24, 2014 at 6:05 PM, Reto Gmür <[email protected]> wrote: > 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 > >> > >> > > >
