+1 on this. Having the flexibility to have individual release cycles for each component will be huge advantage for us. However as Justin mentioned, we shouldn't rule out a Qpid wide release perhaps once a year or so. >From a users perspective this is a great thing to have, bcos all the components bundled under that release will be guaranteed to work well together.
Rajith On Wed, Apr 10, 2013 at 10:46 AM, Rob Godfrey <[email protected]>wrote: > I'm +1 this... Obviously we need to understand better the amount of work to > achieve the separation of the components... but if this were in place then > we wouldn't be facing the sort of issues we are currently experiencing with > the 0.22 release which would strongly benefit from not having the release > cycles of all components tied together. > > -- Rob > > > On 10 April 2013 15:55, Justin Ross <[email protected]> wrote: > > > Hi, everyone. We've recently been discussing the components of our > > project in a couple different contexts. This is a proposal to take > > the outcomes of those discussion and apply them to how Qpid is > > organized. > > > > Thanks for taking a look, > > Justin > > > > ## Related discussions > > > > - > > > http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html > > - http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html > > > > ## The problem > > > > For a long time, Qpid was in many respects treated as one thing, with > > one release cycle. Its parts were divided at the top level by > > language, not function. > > > > The division by language provides little incentive to factor out > > dependencies into clean interfaces, and it has tended to mean that > > developers often work in just one language silo. > > > > It has also meant that our source modules have only a weak > > correspondence to the user-focused release artifacts that we produce. > > > > With Proton, we've broken the mold, and the overall picture of Qpid is > > inconsistent and confusing, to the Qpid developers and users. > > > > ## The proposed approach > > > > - Qpid the project embraces a functional division of components > > > > - Each source component is self-contained and independent, with a > > focused purpose; among components, there are well defined > > dependencies > > > > - The source components should correspond closely to the pieces our > > users want to use independently; nonetheless, there would in some > > cases be multiple release artifacts from a component > > > > - Each component has its own set of branches, supporting independent > > releases > > > > - Each component should be neither too large nor too small; large > > enough to ease development and release management; small enough to > > represent a focused functional unit and to clarify dependencies > > > > - API components would in some cases also contain code shared by APIs > > and servers; the server would in that case depend on the API code > > base > > > > ## Proposed source components > > > > - Proton (this one already exists) > > - /qpid/proton/trunk/ > > > > - JMS > > - /qpid/jms/trunk/ > > - Depends on Proton > > > > - Java broker > > - /qpid/java-broker/trunk/ > > - Depends on JMS (?) > > > > - Messaging API > > - /qpid/messaging-api/trunk/ > > - Both the C++ (and bindings) and python implementations would > > move here > > - Depends on Proton > > > > - C++ broker > > - /qpid/cpp-broker/trunk/ > > - Depends on Messaging-API > > > > Note that this matches the download page of the new website pretty > > nicely. > > > > - http://people.apache.org/~jross/transom/head/download.html > > > > There's some debate about the right names for these things. Don't > > take my suggestions seriously. I just had to put something down to > > illustrate. If I had my druthers, we'd give the two brokers names > > that didn't include a programming language. > > > > ## First steps > > > > This change can't happen all at once. We propose to start with these: > > > > - Isolate JMS from the existing qpid/trunk/qpid tree > > - Isolate the Messaging API from the existing qpid/trunk/qpid tree > > > > If this is agreed, the idea is to bite off this much during the 0.24 > > cycle. > > > > ## Developer infrastructure > > > > This change calls for some work to support developers using multiple > > components in one development environment. This needs more > > investigation. > > > > ## JIRA instances > > > > We propose *not* to create new jira instances for each component. We > > can do that later on if necessary. For now we can overload the > > version field in the qpid jira instance to include a component name. > > > > ## A Qpid "distribution" of source component releases > > > > While this scheme supports independent releases of each source > > component, it doesn't rule out a Qpid-wide release. There may be > > reason for Qpid as a whole to share a release cadence and > > produce a new "distribution" of components each cycle. It would all > > be more flexible, however. A component might want to produce three > > revisions in the space of a standard Qpid-wide four-month cycle, or a > > component might produce no new revisions. > > > > To me the advantage of producing a periodic distribution is (a) > > coordinated testing and (b) a known distribution set for users to > > deploy together. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
