There was already another thread on this topic along with a Jira: http://activemq.2283324.n4.nabble.com/DISCUSS-Draft-proposal-for-terminology-change-td4758351.html https://issues.apache.org/jira/browse/AMQ-7514
New terms were already somewhat decided in that thread as primary/backup doesn't make sense in all cases. It depends on what the application is (leader/follower, etc) On Tue, Nov 10, 2020 at 12:05 PM Jean-Baptiste Onofre <[email protected]> wrote: > Hi, > > I agree with the terms (I think we have kind of consensus). > > I will start the change on ActiveMQ side (as I’m working on new releases > and updates). > > Regards > JB > > > Le 10 nov. 2020 à 17:26, Clebert Suconic <[email protected]> a > écrit : > > > > What about this... lets propose the following changes: > > > > - master should become primary (we could refer to it as primary server > in docs) > > - slave should become backup (same way, we could refer to it as backup > > server in docs) > > - whitelist: allowlist > > - blacklist: denylist > > > > TBH: master and slave are the most used words among the list, on both > > activemq and artemis codebase. > > > > > > I'm working with my company (Red Hat) to allow time from someone on > > our team to work on this, and I believe we can set up someone > > dedicated to it early 2021 on the ActiveMQ Artemis codebase. > > > > We still need volunteers to do it on the ActiveMQ codebase.... > > > > > > In regard to the list of names, I am not particularly strongly > > opinionated with the terms.. but if someone is, please suggest a > > different term to the list. > > > > > > > > > > > > > > > > On Mon, Nov 9, 2020 at 3:38 PM Rich Bowen <[email protected]> wrote: > >> > >> > >> > >> On 2020/11/05 17:34:25, Clebert Suconic <[email protected]> > wrote: > >>> *My* particular issue around this was not knowing what to do with > >>> configuration parameters and APIs. > >>> > >>> If we simply remove those, older clients, older configs would not > work any > >>> longer. > >>> > >>> Is deprecation here a valid approach? Is there consensus around it ? > >> > >> Yes, we definitely recommend that you have a published deprecation > plan, so that there's sufficient warning, and you don't break existing > installations. Exactly what that timing is, is going to vary a great deal > from one project to another, and only you and your users can figure that > out. > > > > > > > > -- > > Clebert Suconic > >
