Hi Minto On Mon, Aug 25, 2014 at 8:31 AM, Minto van der Sluis <[email protected]> wrote:
> Hi Reto, > > Unfortunately I have no clear vision on which direction to go. I guess > this is mainly caused by my focus on the rdf.* artefacts. > > Let me try to sum it up: > 1) Release all and release often > pros: > - For us this is probably easiest to do (from release perspective) > - The whole thing works together (from user perspective) > cons: > - Re-releasing modules with new version numbers without actual changes. > - Whole thing has to work together before being able to release > (from dev perspective) > > 2) Release individual components > pros: > - Only release what has changed. Small chunks. > - easier to release often > cons: > - Quite a hassle in the current project structure > - Users have to mix and match individual artefacts themselves. > > There are probably some other pros and cons as well for each of these. > > However I was wondering if there maybe is something in between. Like > instead of releasing all individual components, releasing larger > functionally separate chunks. For instance (this is just an example): > Rdf, Web, Platform, Utils and maybe a few others. > What is the benefit of "grouping" to a larger chunks in the release process? How to group? Probably by looking to dependent modules? In this case, it is just option A in the first email of Reto. cheers hasan > > Does this make any sense? > > Regards, > > Minto > > > Reto Gmür schreef op 24-8-2014 18:05: > > 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 > >>> > >>> > > > -- > ir. ing. Minto van der Sluis > Software innovator / renovator > Xup BV > > Mobiel: +31 (0) 626 014541 > >
