This reminds me, Hadoop has some java annotation mechanism for public vs private, including a concept of "stable" vs "subject to change".
Mahadev what do you think of this? Something we should adopt? Patrick On Thu, Oct 27, 2011 at 9:31 AM, Mahadev Konar <[email protected]> wrote: > Thomas, > Doesnt look like its a blocker to me. It isnt a public API. Renaming > should be fine. Jute doesnt serializes the name of the record. So as > long as the fields and opcode are the same, it should be backwards > compatible as well. If you have a simple enough patch for rename I can > include it in 3.4 as well (just to avoid any complications regarding > backwards/forward compatibility later). Sounds reasonable? > > thanks > mahadev > > On Thu, Oct 27, 2011 at 8:50 AM, Patrick Hunt <[email protected]> wrote: >> Submit a patch and slate it for 3.4.0/3.5.0, Mahadev can decide >> whether he wants to include it in the next rc or not. >> >> Patrick >> >> On Thu, Oct 27, 2011 at 2:57 AM, Thomas Koch <[email protected]> wrote: >>> Hi, >>> >>> I've opened ZK-1257 with this description: >>> >>> <quote> >>> Understanding the code behind multi operations doesn't get any easier when >>> the >>> code violates naming consistency. >>> All other Request classes are called xxxRequest, only for multi its >>> xxxTransactionRecord! Also "Transaction" is wrong, because there is the >>> concepts of transactions that are transmitted between quorum peers or >>> committed to disc. MultiTransactionRecord however is a Request from a >>> client. >>> </quote> >>> >>> I think the rename could also happen after 3.4 since MultiTransactionRecord >>> is >>> not part of the API? If not, I strongly recommend to do the rename before >>> the >>> release. >>> >>> Regards, >>> >>> Thomas Koch, http://www.koch.ro >>> >> >
