Thanks all - "Does backwards compatibility matter in all cases?" seems to have struck a chord, even for a one character change.
@terence - good summary. @fred - There is a sub group here that sets the direction - it's called the PMC (project management committee), and the chair of the PMC facilitates important decisions. It's consensus driven... which does not mean we all have to agree. For my part, this seems like a normal discussion and the technical direction seems good. James PMC Chair On Mon, Dec 29, 2025 at 6:52 AM Monica <[email protected]> wrote: > Hello Terence, > Thank you for the guidance and for confirming the approach. I really > appreciate it. > I have fixed the typo across the codebase (domain models, services, SQL > aliases, API layers, and tests). I am now validating the changes to make > sure nothing breaks. As discussed, I am also checking how best to keep > backward compatibility for the API (for example, using @JsonAlias) and > understanding the actual effort involved. > Before submitting the PR, I would like some more time to: > > - Run and review the full test suite, > - Fix any test failures caused by the rename, > - Clearly note where backward compatibility is easy and where it may > be more complex. > > This will help me submit a PR with clear findings rather than assumptions, > so we can decide the best path forward together. > Thank you again for your patience and guidance. I will follow up with the > PR and details soon. > Best regards, > Monica > > ------------------------------ > *From:* Terence Monteiro <[email protected]> > *Sent:* Monday, December 29, 2025 12:23 > *To:* [email protected] <[email protected]> > *Subject:* Re: [FINERACT-2206] guidance on proposed backward-compatible > fix approach > > > Monica, > > Thank you for asking before starting the work. This is the right approach. > > *The Situation:* > > - Felix found the typo and suggested supporting both spellings for the > API > - Adam Saghy agreed with your backward-compatible approach on JIRA > - Victor researched the scope and found 142 occurrences in 35 files > - Victor wants to fix the typo cleanly > - Wilfred and Fred are concerned about breaking frontend/client code > - Your research confirmed this spans multiple layers: domain models, > API parameters, constants, SQL aliases, Swagger docs, tests > > All of these points are valid. > > *My Suggestion:* > > 1. Fix the spelling in the code > 2. Check how much work it takes to keep backward compatibility (using > @JsonAlias like you suggested) > 3. Show us what you find > > When you submit the PR, we can see the actual code and decide together. > This is better than guessing now. > > *Why Both Matter:* > > - Code quality: we should fix typos > - Our ecosystem: partners have built frontends on our API > > *Your Time Matters:* Whatever you find will help the project. If backward > compatibility is simple, great. If it's complex, we need to know that too. > > Thank you for being patient and asking good questions. This is how good > open source works. > > Looking forward to your PR. > > Best regards, > Terence Monteiro > Member, Apache Fineract PMC > > On Mon, Dec 29, 2025 at 4:35 PM Monica <[email protected]> > wrote: > > Hi all, > Thank you for the thoughtful discussion so far — it’s been really helpful > to understand the different perspectives. > To summarize my understanding so far: > > - The misspelling allowPartialPeriodInterestCalcualtion is clearly a > typo and appears extensively across the codebase, API surface, > documentation, and tests. > - Fixing it everywhere would be a non-functional improvement > internally, but it *does touch the client-facing API*, which > introduces a real risk of breaking existing integrations. > - Some feedback suggests fixing the typo outright and moving forward > cleanly. > - Other feedback highlights the impact on frontend/client consumers > and suggests keeping backward compatibility (for example via aliasing and > deprecation). > > Before I proceed further and invest time in an implementation that might > not align with the project’s expectations, I’d really appreciate a clear > direction from the maintainers on this point: > *Should the fix:* > > 1. Correct the typo everywhere without maintaining backward > compatibility, or > 2. Introduce the corrected field while still supporting the old one > for backward compatibility (with deprecation and documentation)? > > I’m completely happy to follow whichever approach the project prefers — my > main goal is to implement this in a way that is correct, acceptable, and > useful for the community. > Thanks again for the guidance and for taking the time to help clarify this. > Best regards, > Monica > > ------------------------------ > *From:* Kigred Developer <[email protected]> > *Sent:* Monday, December 29, 2025 10:26 > *To:* Dev <[email protected]> > *Subject:* Re: [FINERACT-2206] guidance on proposed backward-compatible > fix approach > > @Victor, Thanks for the work. > > From the the front end perspective of things, the backward compatibility > would be nice to maintain with the deprecation message in the release. > Imagine having to redo about 3 frontend or solutions because of a new > release. > > My 2 cents. > Wilfred > > On Mon, 29 Dec 2025, 07:20 VICTOR MANUEL ROMERO RODRIGUEZ, < > [email protected]> wrote: > > Could you please share your feedback about the questions I have raised? > Your response are very important to understand the impact of the change. > > Regards > > Victor > > El dom, 28 dic 2025 a las 22:17, Fred Amaral (<[email protected]>) > escribió: > > thanks, victor. > > On Mon, Dec 29, 2025 at 1:10 AM VICTOR MANUEL ROMERO RODRIGUEZ < > [email protected]> wrote: > > No. > > I have given my response since the very first email, don’t maintain the > typo. > > And what do you think? Are you using any API of Core banking directly from > dev? or are you using a release version ? If so (about using the core > banking), which is the effort for making the change on the interface with > the fix? > > Your feedback is appreciated. > > Regards > > Victor > > El dom, 28 dic 2025 a las 22:04, Fred Amaral (<[email protected]>) > escribió: > > should her keep back-comp or not? > > -- > Fred > - m: +55 11 984 811 139 > > > On Mon, 29 Dec 2025 at 1:00 AM VICTOR MANUEL ROMERO RODRIGUEZ < > [email protected]> wrote: > > Fred, > > I have given my point of view about not maintaining the typo. She is aware > about the points to take care of since the first email. I just add the > times/files as statistics. > > And I think if we focus on fixing it and having talks around the technical > debt, we can try to close it as much as possible while being clear > about functional and nonfunctional changes. > > This list is an open and multidirectional communication channel for > transparency and also your feedback is valuable in the Fineract JIRA > https://issues.apache.org/jira/browse/FINERACT-2206 for adding comments. > > Regards > > Victor > > El dom, 28 dic 2025 a las 21:43, Fred Amaral (<[email protected]>) > escribió: > > the issue touches client interface. the misspelling is a typo but if fixed > in the 30+ occurrences as mentioned by you, this will likely break the > client. whats the take of the group before making monica working on a pr > that will be rejected if not properly back-comp created? this is the advise > we should be giving her. > > -- > Fred > - m: +55 11 984 811 139 > > > On Mon, 29 Dec 2025 at 12:38 AM VICTOR MANUEL ROMERO RODRIGUEZ < > [email protected]> wrote: > > Fred, > > I think this is a typo. Which is a non functional requirement. > > I have asked her to send the PR for review and explain briefly that it > will execute testing, code/doc review and then it will be included in a > release (because the PR could be included in one). > > How can you improve the discussion by giving more feedback? > > Happy to read you. > > Regards > > Victor Romero > > > > El dom, 28 dic 2025 a las 21:30, Fred Amaral (<[email protected]>) > escribió: > > unfortunately, this is why a democratic project does not fly. there must > be one setting the guardrails. monica is working hard to make things evolve > and we basically tell her “do the process and we will figure it out in the > end that it breaks clients and reject the PR”. gosh, guys… > > sometimes i remember the threads i read from linus and i understand why > that project works til today. > > -- > Fred > - m: +55 11 984 811 139 > > > On Mon, 29 Dec 2025 at 12:12 AM VICTOR MANUEL ROMERO RODRIGUEZ < > [email protected]> wrote: > > Yes. 142 times in 35 files. > > If it passes the testing, the code review and also in the documents the PR > will go to the "develop" branch and in the future it could be included in a > release. > > Please share the PR for a technical/doc review. > > Regards > > Victor Romero > > El dom, 28 dic 2025 a las 19:05, Monica (<[email protected]>) > escribió: > > Hi Victor Romero, > Thanks for taking a look and for the clarification. I understand the point > about this being a single typo and will submit the PR shortly. > However, while digging deeper, I noticed that this typo ( > allowPartialPeriodInterestCalcualtion) is currently propagated across > multiple layers — domain models, API parameters, constants, SQL aliases, > Swagger docs, legacy HTML docs, and even integration/e2e tests. Because of > that, it seems to have effectively become part of the public API and > persisted contract. > My concern is that directly fixing the spelling everywhere might > unintentionally break existing clients or integrations that are already > using the misspelled field name. From that perspective, I was wondering > whether it would be safer to handle this in a backward-compatible way (for > example, supporting both the old and corrected parameter names, with > deprecation guidance). > I wanted to check with you before proceeding further, to make sure the > approach aligns with the project’s expectations and avoids any regressions > for existing users. > Happy to follow whatever direction you feel is best here — just wanted to > raise this before making changes. > Thanks again for your guidance, > Monica > > ------------------------------ > *From:* VICTOR MANUEL ROMERO RODRIGUEZ <[email protected]> > *Sent:* Sunday, December 28, 2025 15:51 > *To:* [email protected] <[email protected]> > *Subject:* Re: [FINERACT-2206] guidance on proposed backward-compatible > fix approach > > Waiting for your PR in order to review it. > > Thank you in advance for your code contribution. > > Regards > > Victor Romero > > El sáb, 27 dic 2025 a las 23:58, Monica (<[email protected]>) > escribió: > > Thank you for your guidance > Will keep it in mind. > > Regards > Monica > ------------------------------ > *From:* VICTOR MANUEL ROMERO RODRIGUEZ <[email protected]> > *Sent:* Saturday, December 27, 2025 18:42 > *To:* [email protected] <[email protected]> > *Subject:* Re: [FINERACT-2206] guidance on proposed backward-compatible > fix approach > > Hello, > > This is a one character typo. Just fix it and don’t maintain the typo. > > Regards > > > > El El sáb, 27 de dic de 2025 a la(s) 7:30 a.m., Monica < > [email protected]> escribió: > > Hello Fineract Maintainers, > I hope you’re doing well. > I’m planning to work on * FINERACT-2206* and wanted to confirm the > proposed approach with you before starting implementation, to ensure it > aligns with the project’s expectations and best practices. > Jira issue link: [FINERACT-2206] Rest API und code contain references to > the misspelled "allowPartialPeriodInterestCalcualtion" - ASF Jira > <https://issues.apache.org/jira/browse/FINERACT-2206> > Based on my understanding of the issue, the plan would be: > > 1. Identify all occurrences of the misspelled field > allowPartialPeriodInterestCalcualtion across the Java codebase and > REST API. > 2. Introduce the correctly spelled field > allowPartialPeriodInterestCalculation as the primary/internal > representation. > 3. Maintain backward compatibility for the REST API by supporting both > spellings (for example, using Jackson annotations such as @JsonAlias), > while favoring the correctly spelled version going forward. > 4. Update API documentation / OpenAPI specs to reflect the corrected > field name. > 5. Add or update tests to ensure both spellings are accepted and > existing clients are not broken. > 6. Mark the misspelled field as deprecated where appropriate. > > Before proceeding, I’d really appreciate your confirmation on: > > - Whether supporting * both spellings* for backward compatibility is > the preferred approach. > - Any specific guidelines or constraints you’d like me to follow while > implementing this fix. > > Once confirmed, I’ll go ahead and prepare a PR referencing * > FINERACT-2206*. > Thank you for your time and guidance. > Best regards, > Monica > >
