I certainly wouldn't mind it being seperated, it would have been nice to do years ago, with the only thing stopping it being the time/effort. Its certainly a better end result, so if you are willing..
If the client is to be separated though, I don't see a particular need or benefit to jumping its version number ahead again. If anything I'd only change the broker if they were to change out of step, which is essentially already happening naturally. I say that because it would seem a bit strange to me to increase the client version number significantly while making no major changes and while seperating it in large part because its expected to be in maintenance mode (especially with the example taking it to having by far the highest version number, which at least in part would often signify the opposite to me). I think I'd probably do what Rob suggested and version it as 6.2 (maybe jumping to a higher 6.x to allow for a 6.2 etc based on current 6.1, however unlikely that may be). With the broker already progressing to 7 that would start things off at a different point already, and then likely diverge a reasonable amount over a fairly short time given expectations for the two. That along with them actually being be separate, and presumably getting released at different times/frequencies going forward, should all help signal their independence well enough in my mind. If separating, the other thing would of course be naming/location decisions for broker and client. I'll also drop in as a final note that these are the only two actively released components still in the SVN repo and that might be something to consider during this effort. Robbie On 12 January 2017 at 09:05, Keith W <[email protected]> wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
