On 12 January 2017 at 14:22, Keith W <[email protected]> wrote: > The idea to jump the version number of the client was to clearly > differentiate it from the previous release where broker/client were > released together. I accept that such a change might cause confusion > and lead some users to believe the legacy client to be the latest and > greatest. I'd be happy with calling the release 6.3. I'm imagining > prominent notes on the Qpid Broker for Java and 0-x client components > pages emphasising the fact that the two components are released > separately. >
Yes, I think the site and all the other factors, coupled with the broker going to 7.x and the client not, would communiciate the change more clearly than bumping the client version significantly which could cause more confusion. > With regarded to version control mechanism, I do dearly want to move > both Qpid Broker for Java and the 0-x client to GIT. Having one > Apache project use both SVN and GIT is just plain ugly and puts > barriers for folks wanting to get involved. However, our timetable > for a next few months is already overfull, I think to delay the GIT > migration for the moment for time being, possibly to just after the v7 > release. If we have capacity, I will move that forward. > > So, for the moment, I suggest these components remain SVN in the following > way: > > https://svn.apache.org/repos/asf/qpid/java/ - will continue to house > everything it houses today (Broker, Integration Tests etc) except for > 0-x client and 0-x client docs. > https://svn.apache.org/repos/asf/qpid/qpid-jms-client-amqp-0-x - a > new repository created for the rehired 0-x client. The Maven > artefact name will remain unchanged (qpid-client) I'd be fine with that (maybe drop 'client' from the 'repo' name to align, and avoid containing the other clients artifact name). That said, having made the transition a few times now its worth saying its not that much effort normally, especially compared to the rest of the change here. In some ways I think making the changes would be less painful if done while/after moving to git, and similarly for any ongoing backporting efforts. It is a while since a move was deferred for the last reorg :) > > On 12 January 2017 at 11:42, Robbie Gemmell <[email protected]> wrote: >> 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]
