Hi Fraser,
It's always a bit of a juggling act isn't it?
My thinking was that since the feature is now gone on the broker, it is
confusing to keep it in the tools. However you have a point about new tools
against old brokers.
Do you think we should keep the old features in the tools and put a deprecation
in the release notes, then take them out next cycle? That would mean that we
have to test that new tools do actually work with old brokers, which is
something we haven't done so far (but probably should)
Cheers,
Alan.
On 10/05/2013 06:37 AM, Fraser Adams wrote:
Hey Alan,
I finally got round to playing with this - I noticed it was part of the mammoth
svn update I did this morning. It all looks fine to me. As I say thanks for
being so thorough about tidying up everything that refers to this.
One very minor thing struck me the other evening after I'd thought about this
change - it's not all that uncommon for people to be running systems that may
contain a "mixed economy" of broker versions. It's clearly not a huge deal as
the versions of the tools deployed with the earlier instances with work with
those and 0.25+ but the opposite isn't true for the case of cluster-durable and
that might cause some confusion.
I only note this as I've got entertaining memories of the time when I has a
mixture of 0.8 and 0.18 in a very large federated topology. Between those
versions things had been updated to use pure QMF method invocation for
adding/deleting things so the 0.18 tools failed miserably on the 0.8 brokers but
the 0.8 tools still worked with the 0.18 brokers - thank goodness :-D .
Fortunately I'm pretty familiar with QMF ;-) so I clocked the issue pretty much
much immediately (when I found out about it!) but the poor sod who's job was
actually to manage the system was tearing his hair out for ages until he thought
to mention his pain to me.
I guess It's a challenge trying to keep things abreast (and tidy) with
improvements whilst also keeping older/mixed systems running and I don't have
any good answers myself (just saying "upgrade" doesn't cut it in an Enterprise
environment). Documenting the change *might* work, but in this case where on
earth would one put it where someone who may get bitten by this change would
find it?
I've got no real issues myself, but thought it was worth mentioning it as a bit
of food for thought in case someone has any bright ideas how to manage this sort
of scenario (it's bound to crop up again).
Cheers,
Frase
On 01/10/13 22:43, Alan Conway wrote:
On October 1st, 2013, 6:47 p.m. UTC, *Fraser Adams* wrote:
Ship It!
On October 1st, 2013, 6:55 p.m. UTC, *Fraser Adams* wrote:
Hi Alan, I've been tied up for ages on a bunch of other things so I
probably won't get a change to "fire it up" until the weekend to actually kick
it, however I have had a look through the diffs and it all looks fine to me.
I have to say that I'm impressed by how thorough you've been. I did a
double take when I saw the GetOpt helper mentioned cause I couldn't recall it
having any such dependencies - but you've even tidied up references that were
just mentioned as comments - nice one!
As long as you've fired up the GUI and checked the other bits of
"durable" still behave (and from the diff I can't see any reason why they
wouldn't) then I'm cool, but it'd definitely be good to double check - that
expansion animation was a little fiddly :-) Visually though it looks fine to me.
Great. I will try to figure out how to fire up the GUI myself, if you don't get
to it first.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
