My only disagreement is timing. I'd prefer we make the effort to re-home the AMQP 0-x client in SVN now. Once done, we would make a 'major' 0-x client release carrying a new major version number. The new major version (say 13.0) would help users break the notion that Qpid Broker for Java and the 0-x client are somehow 'paired'. We'd schedule the major release approximately about the time we release Qpid Broker for Java v7, but, from then forward the two products' release cycles would break step, with hopefully, just a little defect fix work continuing on the AMQP 0-x client.
I think this approach will also fit in naturally with the existing mechanics behind the q.a.o component and release pages. I'm willing to put the time in to make this happen. On 11 January 2017 at 19:11, Robbie Gemmell <[email protected]> wrote: > Sounds good to me. > > On 11 January 2017 at 19:04, Rob Godfrey <[email protected]> wrote: >> So my feeling is that at this point if we want to do another feature >> release of the 0-x JMS client we could separate it from the 6.1.x release >> rather than current trunk, and we could do that as and when we need to. >> That is if we only do bug fixes we'd continue on 6.1.x... If we need a new >> feature release we'd separate out a v6.2 or v<insert random version number >> here> client release. Cutting it from trunk / v7.0 doesn't imply we'd >> never do another release... nor that we'd never separate it... just that we >> don't need to separate it until we actually have a feature release we want >> to prepare. >> >> -- Rob >> >> On 11 January 2017 at 19:45, Robbie Gemmell <[email protected]> >> wrote: >> >>> On 11 January 2017 at 14:39, Rob Godfrey <[email protected]> wrote: >>> > Splitting out this conversation from the "Ending support for Java 7" >>> > discussion. >>> > >>> > Currently the Qpid for Java release contains a Broker and an AMQP 0-x >>> > client. New users should be using the AMQP 1.0 JMS client which is >>> > released as a separate component. The AMQP 0-x client is really in >>> bugfix >>> > mode only at this point. As such I'm not sure it makes sense to continue >>> > to release "new" versions of the 0-x client on the 7.0 line. >>> > >>> > We had already expressed a desire to split the Broker and Client releases >>> > however there is a lot of (ill-defined) common code used by both >>> > components. Trying to separate and maintain both components seems overly >>> > onerous when, in practice, the AMQP 0-x client is all but deprecated. >>> > Moreover we will likely anyway be backporting any client bugfixes to the >>> > 6.1.x branch whether or not we remove (or separate) the client in 7.0. >>> As >>> > such the client in the 6.1.x package would be functionally identical to >>> and >>> > 7.x client. >>> > >>> > Given the extra work involved in separating, and the fact that whatever >>> we >>> > do changes made to the 0-x client would likely be going into the 6.1.x >>> > branch anyway, I propose that we drop the AMQP 0-x client from the 7.0 >>> > release. >>> > >>> > Thoughts, comments? >>> > >>> > -- Rob >>> >>> I can see that it would be nice to have a seperate 0-x client release, >>> but it is a fair bit of work to set that up. If as you say essentially >>> every change would get backported to 6.x it ends up being equivalent >>> to not bothering (overlooking the reduced work from not backporting an >>> extra time). The backports would as things stand also necessitate >>> releasing the 6.x broker even if not strictly needed so that wouldnt >>> really change either (always having been the case thus far), short of >>> also separating the client from 6.x to really get the benefit of doing >>> it, which would be more effort again. >>> >>> I guess the decision comes down to, do the benefits outweigh the >>> effort required for those doing the work, as well as perhaps >>> consideration of how long there is intent to keep doing 6.x releases. >>> I think it would have in the past, but with the idea being around for >>> a number of years at this point I'm not sure it does now. >>> >>> Robbie >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
