my pain point was: "fix the typo, submit pull request, and then we will see". but all good now. thanks, james.
On Mon, Dec 29, 2025 at 1:13 PM James Dailey <[email protected]> wrote: > 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 >> >>
