Hasan Hasan schreef op 26-8-2014 06:06: > 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. How to do a release? As in what steps to take? How to instruct the build server to create that release?
In my opinion doing a release should not require one to make other changes to the sources (including pom.xml files) than changing the version number. In fact doing a release should just be starting a job on the build server (if not doing continuous delivery). When doing that release the build job will most likely also add a tag in our git repository. Then what is being tagged? Not just the module under release but the whole repository. So if we want to release per module I agree with Reto that we should have a repository per module as well. If so, shouldn't we also have issue tracking per module as well? To me this is too fine grained. If releasing per module is too fine grained. And if releasing all at once is to coarse grained. Wouldn't grouping modules in a logical way then be an acceptable trade off? > > 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 >> >> -- ir. ing. Minto van der Sluis Software innovator / renovator Xup BV Mobiel: +31 (0) 626 014541
