On Tue, Aug 26, 2014 at 8:23 AM, Minto van der Sluis <[email protected]> wrote:
> 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? > It should be mvn release:prepare mvn release:deploy Go to: https://repository.apache.org/ and close the release, call for vote and if it succeded promote the release. Upload the source release and its signature to https://dist.apache.org/repos/dist/, update website The release is not built by the build server but locally. > > 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. the mvn release plugin takes care of chaning the version numbers. > 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. > The suggested tas for the latest unsuccssull attempt to tailor a release was typehandlerspace-0.2. > > 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. > An issue might span different modules and I don't see any big issue keeping this as it is. > > 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? A grouping similar to the features might be an option. But personally I prefer the more fine grained approach. Cheers, 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 > >> > >> > > > -- > ir. ing. Minto van der Sluis > Software innovator / renovator > Xup BV > > Mobiel: +31 (0) 626 014541 > >
