Hi, <snip> >
> > As an end user I can see the advantage of downloading a single binary >> package however I don't then want to have to pick through over 60 jar >> files to find the require dependencies for my client code. I would >> much prefer to have individual packages so that we can then patch and >> release changes as required. If there is a critical bug in the client >> code we shouldn't have to do a full Qpid release. >> > > I don't think as an Apache project we would ever want to do separate > releases of particular sub-component, but I can see how it would be useful > for those commercial entities providing support for Qpid to be able to do > that sort of thing. So for me, this becomes a nice to have sort of thing, > but not really a priority for an Apache release. >> >> >>> >> >> Most of my work is about user interaction .... I think having distinct distros, regardless of how we do releases and what we include, is really useful. For example, most (almost all) users do not want to use their client on the same env as their broker. Thus one big distro forces them to install a heap of stuff they don't want to use. It also makes it far harder (in most controlled environments) to manage the versions of Qpid in use i.e. the broker & client package is all in one. Much easier to work here where the client & broker are separate. I know users who have been bitten by this, and it applies equally to Apache release distros. We may want to do releases of individual components (we have done in the past). There's no reason why we could not at any rate. I use scripts to generate what I'd like to use, so am happy to go with the majority on Apache releases. Just my tuppence from the coalface so to speak. I am pretty ambivalent about how we do it, both approaches have real merit but i think the output is the key item for me. TTfn, Marnie
