Gary, that makes sense to me as I think making sure everything is backwards compatible for existing users is important. (not just for openwire but all config, etc) There would need to be some work done in the broker to know which properties to use based on the negotiated openwire version and be able to fall back to old variables and config if needed.
On Tue, Jul 14, 2020 at 7:51 AM Gary Tully <gary.tu...@gmail.com> wrote: > I think for openwire, rename and a change in openwire version is the way > to go. > keeping the old terms around for backward compatibility is both > sensible and necessary. > > On Tue, 14 Jul 2020 at 11:42, Christopher Shannon > <christopher.l.shan...@gmail.com> wrote: > > > > I agree that it is time to make the change. Justin made a good point in > > that we should make sure to pick the best and most descriptive names > > possible for the use case. Whether that is follower/leader, > > primary/secondary, primary/replica, live/backup, etc. I think live/backup > > certainly makes a lot of sense for Artemis. For 5.x I think it also makes > > sense but primary/secondary is fine too. > > > > My main concern here is how do we handle the technical issues with > > compatibility? For example, do we just deprecate the old configuration > and > > terminology to not break users or do we rip it out entirely initially > which > > would be a breaking change for users that needs to be well communicated? > > For Artemis, maybe we deprecated in 2.x and in 3.x. > > > > Another thing is some things will be easy to change and others not so > > much. For something like the LevelDB store that uses the terminology > this > > is easy as we can just remove it entirely as we plan to remove it in 5.17 > > anyways. However, one thing that does seem like a challenge to fix is > > OpenWire. For example the BrokerInfo command actually uses the terms > > slaveBroker and masterBroker. Renaming these would now break > compatibility > > with brokers running older versions of 5.x. I think the only way it > would > > work is to keep the terms around for the older versions of OpenWire and > > then generate a new version that has them renamed which I'm not sure if > > that is or isn't acceptable as the software would still be distributed > with > > those older terms laying around. > > > > On Mon, Jul 13, 2020 at 11:57 PM Xeno Amess <xenoam...@gmail.com> wrote: > > > > > They did? > > > OK, then I have no more doubts. > > > > > > Justin Bertram <jbert...@apache.org> 于2020年7月14日周二 上午11:42写道： > > > > > > > For what it's worth, GitHub is changing the default branch name so > > > there's > > > > no argument to be had with them as you suggest. See here [1] for > example. > > > > > > > > > > > > Justin > > > > > > > > [1] https://www.bbc.com/news/technology-53050955 > > > > > > > > On Mon, Jul 13, 2020, 10:24 PM Xeno Amess <xenoam...@gmail.com> > wrote: > > > > > > > > > Hi. > > > > > If you really think "master" is something you cannot accept, then > you > > > > might > > > > > argue with github first. > > > > > after all their default git branch name is "master", and github > have > > > far > > > > > more user than ActiveMQ. > > > > > > > > > > Bruce Snyder <bruce.sny...@gmail.com> 于2020年7月14日周二 上午11:03写道： > > > > > > > > > > > Someone mentioned use of the terms 'primary' and 'backup' in the > > > > private > > > > > > list and I liked that suggestion. I'm not wed to any terms > > > necessarily, > > > > > so > > > > > > if Artemis is already using the terms 'live' and 'backup', I'm ok > > > with > > > > > that > > > > > > in ActiveMQ. > > > > > > > > > > > > Bruce > > > > > > > > > > > > On Mon, Jul 13, 2020 at 8:42 PM Justin Bertram < > jbert...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > Thanks for kicking this off, Bruce. > > > > > > > > > > > > > > Among other things the Jira [1] says: > > > > > > > > > > > > > > > 'master' and 'slave' should be replaced with the terms > 'primary,' > > > > > > > 'secondary,' 'tertiary,' etc. > > > > > > > > > > > > > > I would offer "live" and "backup" as suitable replacements for > > > > "master" > > > > > > and > > > > > > > "slave" respectively. The Artemis code and documentation > already > > > use > > > > > > "live" > > > > > > > and "backup" in many places although some instances of > "master" and > > > > > > "slave" > > > > > > > do exist. Aside from the fact that they're already in use I > like > > > the > > > > > fact > > > > > > > that they're relatively short and they clearly capture the > > > underlying > > > > > > > functional semantic. In my opinion the terms "primary," > > > "secondary," > > > > > etc. > > > > > > > are actually a bit vague and they're certainly quite a bit > longer > > > > which > > > > > > > isn't a huge deal but it adds up when writing tests, > documentation, > > > > > etc. > > > > > > > > > > > > > > > > > > > > > Justin > > > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/AMQ-7514 > > > > > > > > > > > > > > On Mon, Jul 13, 2020 at 3:04 PM Bruce Snyder < > > > bruce.sny...@gmail.com > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Given the racial charged nature of certain terms in today's > > > world, > > > > I > > > > > > feel > > > > > > > > that action should be taken to change any such terms in all > the > > > > > > ActiveMQ > > > > > > > > projects. Examples include 'master,' 'slave,' 'whitelist' and > > > > > > > 'blacklist'. > > > > > > > > > > > > > > > > It doesn't matter where these terms originated or how long > they > > > > have > > > > > > been > > > > > > > > used in computer science. I have friends who feel that these > > > terms > > > > > are > > > > > > > > offensive and present a barrier to entry to some. So, I would > > > > prefer > > > > > > that > > > > > > > > they no longer be used anywhere in the ActiveMQ project. The > > > simple > > > > > > fact > > > > > > > is > > > > > > > > that changing these terms will not change the functionality > of > > > the > > > > > > > > features. Furthermore, compared to many other prominent > projects > > > > > > > throughout > > > > > > > > the open source community, ActiveMQ is late to the game on > this > > > > > point. > > > > > > > > > > > > > > > > So, I have created the following JIRA Issue to encapsulate > this > > > > > work. I > > > > > > > > have not assigned any components simply because this should > span > > > > all > > > > > > > > sub-projects and documentation: > > > > > > > > > > > > > > > > https://issues.apache.org/jira/browse/AMQ-7514 > > > > > > > > > > > > > > > > I have already begun work on this effort in a branch in my > own > > > fork > > > > > of > > > > > > > the > > > > > > > > activemq repo. This is to facilitate an eventual pull > request to > > > > the > > > > > > > > ActiveMQ project. Anyone who would like to join me in this > effort > > > > > > please > > > > > > > > reply to this message. > > > > > > > > > > > > > > > > -- > > > > > > > > perl -e 'print > > > > > > > > > > > > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" > > > > > > );' > > > > > > > > http://bsnyder.org/ <http://bruceblog.org/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > perl -e 'print > > > > > > > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" > > > > );' > > > > > > http://bsnyder.org/ <http://bruceblog.org/> > > > > > > > > > > > > > > > > > > >
