You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Rob Godfrey <ro...@gmail.com> on 2017/01/11 14:39:19 UTC
[DISCUSS] Drop the AMQP 0-x client from the Qpid for Java 7.0 release
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
Re: [DISCUSS] Drop the AMQP 0-x client from the Qpid for Java 7.0 release
Posted by Robbie Gemmell <ro...@gmail.com>.
On 9 February 2017 at 13:18, Keith W <ke...@gmail.com> wrote:
> Thanks but I'm aware that there is still outstanding work. LICENSE
> files will be updated and qpid-jms-amqp-0-x-test-utils will almost
> certainly disappear. Separating the two actually proved more painful
> than I anticipated and as a result I needed a staging post.
>
Great. Just pointing things out that aren't mentioned in the JIRAs list.
> I would also like to move both of these to Git, so we have a
> consistent version control story across the whole project. I think to
> schedule this after work is concluded on QPID-7622. This will be done
> before v7.0 is released.
>
Excellent
>
>
> On 9 February 2017 at 11:43, Rob Godfrey <ro...@gmail.com> wrote:
>> +1 on move the new (client) repo to git.
>>
>> I can't see any compelling reason to create a git mirror of this new svn
>> location - we should just be targeting moving all the components onto git
>> this year.
>>
>> -- Rob
>>
>> On 9 February 2017 at 12:38, Robbie Gemmell <ro...@gmail.com>
>> wrote:
>>
>>> The LICENCE and NOTICE files in the new repo will need updating. I
>>> also wondered if the qpid-jms-amqp-0-x-test-utils utils module could
>>> just be factored out? It doesnt seem like its going to be adding
>>> significant value in the new repo to warrant the new module.
>>>
>>> I also wondered about the plan for completing the clients new
>>> repo/area in terms of things like: git mirror, GitHub mirror, GitHub
>>> integrations, Travis/Appveyor CI builds? I ask as it occurs to me that
>>> now would be the next best time to move the repo to Git, before that
>>> work is done, as it would be less work overall for us and infra, cause
>>> less disruption for everyone over time, and give us a better result
>>> now. As I understand things from prior moves, doing so necessitates
>>> infra recreate the Git and GitHub mirrors (plus redo all the
>>> integrations), which in case of the latter also breaks existing forks
>>> off on their own. Given this isnt the first time some of this stuff
>>> has moved it would seem nice not to have to distrupt things yet again
>>> later and get such changes out the way now. Benefits would be avoiding
>>> creating repeated work (mainly for infra, but us too), reducing hassle
>>> for devs/'users', doing away with the annoying sync delays of the
>>> current multi-hop system (it took 32 minutes for the most recent
>>> commit to sync end to end and close its related GitHub PR), and being
>>> consistent within the project.
>>>
>>> Robbie
>>>
>>> On 7 February 2017 at 20:44, Keith W <ke...@gmail.com> wrote:
>>> > I made an initial commit on QPID-7622 separating Qpid Broker for Java
>>> > from the Qpid JMS 0-x Client. The client now lives at
>>> > https://svn.apache.org/repos/asf/qpid/qpid-jms-amqp-0-x. More commits
>>> > will follow over the next few days to eliminate the client-only code
>>> > from the broker. There are also a few refactorings needed in the
>>> > Broker before the 0-8 and 0-10 protocol code can be moved to their
>>> > respective plugin modules.
>>> >
>>> > I have refactored Jenkins to take account of the changes and will be
>>> > monitoring it for the next few days.
>>> >
>>> > Moving the Broker to JDK 1.8 will take place soon once the dust has
>>> > settled, under a separate JIRA.
>>> >
>>> >
>>> >
>>> >
>>> > On 12 January 2017 at 18:13, Keith W <ke...@gmail.com> wrote:
>>> >>>> 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).
>>> >>
>>> >> I'm happy with the suggestion to drop the 'client' part. So, that would
>>> give us:
>>> >> https://svn.apache.org/repos/asf/qpid/qpid-jms-amqp-0-x
>>> >>
>>> >>
>>> >>> 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 :)
>>> >>
>>> >> I think I'd prefer to do the tree surgery in svn. I'm hoping (unless
>>> >> there are more comments on this thread) this work can be done next
>>> >> week.
>>> >> Once the new structure is settled down. I'll look to schedule the move
>>> >> to git as soon as we can.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [DISCUSS] Drop the AMQP 0-x client from the Qpid for Java 7.0 release
Posted by Keith W <ke...@gmail.com>.
Thanks but I'm aware that there is still outstanding work. LICENSE
files will be updated and qpid-jms-amqp-0-x-test-utils will almost
certainly disappear. Separating the two actually proved more painful
than I anticipated and as a result I needed a staging post.
I would also like to move both of these to Git, so we have a
consistent version control story across the whole project. I think to
schedule this after work is concluded on QPID-7622. This will be done
before v7.0 is released.
On 9 February 2017 at 11:43, Rob Godfrey <ro...@gmail.com> wrote:
> +1 on move the new (client) repo to git.
>
> I can't see any compelling reason to create a git mirror of this new svn
> location - we should just be targeting moving all the components onto git
> this year.
>
> -- Rob
>
> On 9 February 2017 at 12:38, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
>> The LICENCE and NOTICE files in the new repo will need updating. I
>> also wondered if the qpid-jms-amqp-0-x-test-utils utils module could
>> just be factored out? It doesnt seem like its going to be adding
>> significant value in the new repo to warrant the new module.
>>
>> I also wondered about the plan for completing the clients new
>> repo/area in terms of things like: git mirror, GitHub mirror, GitHub
>> integrations, Travis/Appveyor CI builds? I ask as it occurs to me that
>> now would be the next best time to move the repo to Git, before that
>> work is done, as it would be less work overall for us and infra, cause
>> less disruption for everyone over time, and give us a better result
>> now. As I understand things from prior moves, doing so necessitates
>> infra recreate the Git and GitHub mirrors (plus redo all the
>> integrations), which in case of the latter also breaks existing forks
>> off on their own. Given this isnt the first time some of this stuff
>> has moved it would seem nice not to have to distrupt things yet again
>> later and get such changes out the way now. Benefits would be avoiding
>> creating repeated work (mainly for infra, but us too), reducing hassle
>> for devs/'users', doing away with the annoying sync delays of the
>> current multi-hop system (it took 32 minutes for the most recent
>> commit to sync end to end and close its related GitHub PR), and being
>> consistent within the project.
>>
>> Robbie
>>
>> On 7 February 2017 at 20:44, Keith W <ke...@gmail.com> wrote:
>> > I made an initial commit on QPID-7622 separating Qpid Broker for Java
>> > from the Qpid JMS 0-x Client. The client now lives at
>> > https://svn.apache.org/repos/asf/qpid/qpid-jms-amqp-0-x. More commits
>> > will follow over the next few days to eliminate the client-only code
>> > from the broker. There are also a few refactorings needed in the
>> > Broker before the 0-8 and 0-10 protocol code can be moved to their
>> > respective plugin modules.
>> >
>> > I have refactored Jenkins to take account of the changes and will be
>> > monitoring it for the next few days.
>> >
>> > Moving the Broker to JDK 1.8 will take place soon once the dust has
>> > settled, under a separate JIRA.
>> >
>> >
>> >
>> >
>> > On 12 January 2017 at 18:13, Keith W <ke...@gmail.com> wrote:
>> >>>> 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).
>> >>
>> >> I'm happy with the suggestion to drop the 'client' part. So, that would
>> give us:
>> >> https://svn.apache.org/repos/asf/qpid/qpid-jms-amqp-0-x
>> >>
>> >>
>> >>> 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 :)
>> >>
>> >> I think I'd prefer to do the tree surgery in svn. I'm hoping (unless
>> >> there are more comments on this thread) this work can be done next
>> >> week.
>> >> Once the new structure is settled down. I'll look to schedule the move
>> >> to git as soon as we can.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [DISCUSS] Drop the AMQP 0-x client from the Qpid for Java 7.0 release
Posted by Rob Godfrey <ro...@gmail.com>.
+1 on move the new (client) repo to git.
I can't see any compelling reason to create a git mirror of this new svn
location - we should just be targeting moving all the components onto git
this year.
-- Rob
On 9 February 2017 at 12:38, Robbie Gemmell <ro...@gmail.com>
wrote:
> The LICENCE and NOTICE files in the new repo will need updating. I
> also wondered if the qpid-jms-amqp-0-x-test-utils utils module could
> just be factored out? It doesnt seem like its going to be adding
> significant value in the new repo to warrant the new module.
>
> I also wondered about the plan for completing the clients new
> repo/area in terms of things like: git mirror, GitHub mirror, GitHub
> integrations, Travis/Appveyor CI builds? I ask as it occurs to me that
> now would be the next best time to move the repo to Git, before that
> work is done, as it would be less work overall for us and infra, cause
> less disruption for everyone over time, and give us a better result
> now. As I understand things from prior moves, doing so necessitates
> infra recreate the Git and GitHub mirrors (plus redo all the
> integrations), which in case of the latter also breaks existing forks
> off on their own. Given this isnt the first time some of this stuff
> has moved it would seem nice not to have to distrupt things yet again
> later and get such changes out the way now. Benefits would be avoiding
> creating repeated work (mainly for infra, but us too), reducing hassle
> for devs/'users', doing away with the annoying sync delays of the
> current multi-hop system (it took 32 minutes for the most recent
> commit to sync end to end and close its related GitHub PR), and being
> consistent within the project.
>
> Robbie
>
> On 7 February 2017 at 20:44, Keith W <ke...@gmail.com> wrote:
> > I made an initial commit on QPID-7622 separating Qpid Broker for Java
> > from the Qpid JMS 0-x Client. The client now lives at
> > https://svn.apache.org/repos/asf/qpid/qpid-jms-amqp-0-x. More commits
> > will follow over the next few days to eliminate the client-only code
> > from the broker. There are also a few refactorings needed in the
> > Broker before the 0-8 and 0-10 protocol code can be moved to their
> > respective plugin modules.
> >
> > I have refactored Jenkins to take account of the changes and will be
> > monitoring it for the next few days.
> >
> > Moving the Broker to JDK 1.8 will take place soon once the dust has
> > settled, under a separate JIRA.
> >
> >
> >
> >
> > On 12 January 2017 at 18:13, Keith W <ke...@gmail.com> wrote:
> >>>> 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).
> >>
> >> I'm happy with the suggestion to drop the 'client' part. So, that would
> give us:
> >> https://svn.apache.org/repos/asf/qpid/qpid-jms-amqp-0-x
> >>
> >>
> >>> 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 :)
> >>
> >> I think I'd prefer to do the tree surgery in svn. I'm hoping (unless
> >> there are more comments on this thread) this work can be done next
> >> week.
> >> Once the new structure is settled down. I'll look to schedule the move
> >> to git as soon as we can.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [DISCUSS] Drop the AMQP 0-x client from the Qpid for Java 7.0 release
Posted by Robbie Gemmell <ro...@gmail.com>.
The LICENCE and NOTICE files in the new repo will need updating. I
also wondered if the qpid-jms-amqp-0-x-test-utils utils module could
just be factored out? It doesnt seem like its going to be adding
significant value in the new repo to warrant the new module.
I also wondered about the plan for completing the clients new
repo/area in terms of things like: git mirror, GitHub mirror, GitHub
integrations, Travis/Appveyor CI builds? I ask as it occurs to me that
now would be the next best time to move the repo to Git, before that
work is done, as it would be less work overall for us and infra, cause
less disruption for everyone over time, and give us a better result
now. As I understand things from prior moves, doing so necessitates
infra recreate the Git and GitHub mirrors (plus redo all the
integrations), which in case of the latter also breaks existing forks
off on their own. Given this isnt the first time some of this stuff
has moved it would seem nice not to have to distrupt things yet again
later and get such changes out the way now. Benefits would be avoiding
creating repeated work (mainly for infra, but us too), reducing hassle
for devs/'users', doing away with the annoying sync delays of the
current multi-hop system (it took 32 minutes for the most recent
commit to sync end to end and close its related GitHub PR), and being
consistent within the project.
Robbie
On 7 February 2017 at 20:44, Keith W <ke...@gmail.com> wrote:
> I made an initial commit on QPID-7622 separating Qpid Broker for Java
> from the Qpid JMS 0-x Client. The client now lives at
> https://svn.apache.org/repos/asf/qpid/qpid-jms-amqp-0-x. More commits
> will follow over the next few days to eliminate the client-only code
> from the broker. There are also a few refactorings needed in the
> Broker before the 0-8 and 0-10 protocol code can be moved to their
> respective plugin modules.
>
> I have refactored Jenkins to take account of the changes and will be
> monitoring it for the next few days.
>
> Moving the Broker to JDK 1.8 will take place soon once the dust has
> settled, under a separate JIRA.
>
>
>
>
> On 12 January 2017 at 18:13, Keith W <ke...@gmail.com> wrote:
>>>> 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).
>>
>> I'm happy with the suggestion to drop the 'client' part. So, that would give us:
>> https://svn.apache.org/repos/asf/qpid/qpid-jms-amqp-0-x
>>
>>
>>> 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 :)
>>
>> I think I'd prefer to do the tree surgery in svn. I'm hoping (unless
>> there are more comments on this thread) this work can be done next
>> week.
>> Once the new structure is settled down. I'll look to schedule the move
>> to git as soon as we can.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [DISCUSS] Drop the AMQP 0-x client from the Qpid for Java 7.0 release
Posted by Keith W <ke...@gmail.com>.
I made an initial commit on QPID-7622 separating Qpid Broker for Java
from the Qpid JMS 0-x Client. The client now lives at
https://svn.apache.org/repos/asf/qpid/qpid-jms-amqp-0-x. More commits
will follow over the next few days to eliminate the client-only code
from the broker. There are also a few refactorings needed in the
Broker before the 0-8 and 0-10 protocol code can be moved to their
respective plugin modules.
I have refactored Jenkins to take account of the changes and will be
monitoring it for the next few days.
Moving the Broker to JDK 1.8 will take place soon once the dust has
settled, under a separate JIRA.
On 12 January 2017 at 18:13, Keith W <ke...@gmail.com> wrote:
>>> 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).
>
> I'm happy with the suggestion to drop the 'client' part. So, that would give us:
> https://svn.apache.org/repos/asf/qpid/qpid-jms-amqp-0-x
>
>
>> 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 :)
>
> I think I'd prefer to do the tree surgery in svn. I'm hoping (unless
> there are more comments on this thread) this work can be done next
> week.
> Once the new structure is settled down. I'll look to schedule the move
> to git as soon as we can.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [DISCUSS] Drop the AMQP 0-x client from the Qpid for Java 7.0 release
Posted by Keith W <ke...@gmail.com>.
>> 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).
I'm happy with the suggestion to drop the 'client' part. So, that would give us:
https://svn.apache.org/repos/asf/qpid/qpid-jms-amqp-0-x
> 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 :)
I think I'd prefer to do the tree surgery in svn. I'm hoping (unless
there are more comments on this thread) this work can be done next
week.
Once the new structure is settled down. I'll look to schedule the move
to git as soon as we can.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [DISCUSS] Drop the AMQP 0-x client from the Qpid for Java 7.0 release
Posted by Robbie Gemmell <ro...@gmail.com>.
On 12 January 2017 at 14:22, Keith W <ke...@gmail.com> 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 <ro...@gmail.com> 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 <ke...@gmail.com> 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 <ro...@gmail.com> wrote:
>>>> Sounds good to me.
>>>>
>>>> On 11 January 2017 at 19:04, Rob Godfrey <ro...@gmail.com> 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 <ro...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On 11 January 2017 at 14:39, Rob Godfrey <ro...@gmail.com> 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: users-unsubscribe@qpid.apache.org
>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [DISCUSS] Drop the AMQP 0-x client from the Qpid for Java 7.0 release
Posted by Keith W <ke...@gmail.com>.
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.
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)
On 12 January 2017 at 11:42, Robbie Gemmell <ro...@gmail.com> 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 <ke...@gmail.com> 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 <ro...@gmail.com> wrote:
>>> Sounds good to me.
>>>
>>> On 11 January 2017 at 19:04, Rob Godfrey <ro...@gmail.com> 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 <ro...@gmail.com>
>>>> wrote:
>>>>
>>>>> On 11 January 2017 at 14:39, Rob Godfrey <ro...@gmail.com> 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: users-unsubscribe@qpid.apache.org
>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [DISCUSS] Drop the AMQP 0-x client from the Qpid for Java 7.0 release
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <ke...@gmail.com> 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 <ro...@gmail.com> wrote:
>> Sounds good to me.
>>
>> On 11 January 2017 at 19:04, Rob Godfrey <ro...@gmail.com> 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 <ro...@gmail.com>
>>> wrote:
>>>
>>>> On 11 January 2017 at 14:39, Rob Godfrey <ro...@gmail.com> 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: users-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [DISCUSS] Drop the AMQP 0-x client from the Qpid for Java 7.0 release
Posted by Keith W <ke...@gmail.com>.
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 <ro...@gmail.com> wrote:
> Sounds good to me.
>
> On 11 January 2017 at 19:04, Rob Godfrey <ro...@gmail.com> 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 <ro...@gmail.com>
>> wrote:
>>
>>> On 11 January 2017 at 14:39, Rob Godfrey <ro...@gmail.com> 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: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [DISCUSS] Drop the AMQP 0-x client from the Qpid for Java 7.0 release
Posted by Robbie Gemmell <ro...@gmail.com>.
Sounds good to me.
On 11 January 2017 at 19:04, Rob Godfrey <ro...@gmail.com> 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 <ro...@gmail.com>
> wrote:
>
>> On 11 January 2017 at 14:39, Rob Godfrey <ro...@gmail.com> 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: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [DISCUSS] Drop the AMQP 0-x client from the Qpid for Java 7.0 release
Posted by Rob Godfrey <ro...@gmail.com>.
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 <ro...@gmail.com>
wrote:
> On 11 January 2017 at 14:39, Rob Godfrey <ro...@gmail.com> 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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [DISCUSS] Drop the AMQP 0-x client from the Qpid for Java 7.0 release
Posted by Robbie Gemmell <ro...@gmail.com>.
On 11 January 2017 at 14:39, Rob Godfrey <ro...@gmail.com> 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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org