Hi Monica, thanks for your questions and everyone's feedback. I am currently working on a slightly similar ticket FINERACT-2422 ( https://issues.apache.org/jira/browse/FINERACT-2422 ) and was about to do a PR. But with my current understanding, I will double check to make sure my code doesn't cause any break .
And I want to thank everyone for their prompt reply. When I had questions of my own, I dare not ask. But now I understand that this is a learning environment and not an exam. So here are my thoughts and Questions, *Files to Review Carefully (Potential Breaking Changes)* * fineract-avro-schemas/src/main/avro/loan/v1/LoanAccountDataV1.avsc* - *Reason:* Avro schemas are used for event-driven integration (e.g., Kafka). Renaming a field in a schema without providing an *alias* or a *default value* can break downstream consumers that are still looking for the old "ageing" spelling. - *Recommendation:* Can I use an *alias* in the Avro schema so it can still read/write data using the old name while transitioning to the new one. *fineract-core/src/main/java/org/apache/fineract/infrastructure/jobs/service/JobName.java* - *Reason:* Enums like JobName are often persisted in the database (e.g., in the scheduled_job table). If you rename the enum constant itself (e.g., UPDATE_LOAN_ARREARS_AGEING to UPDATE_LOAN_ARREARS_AGING), the existing records in the database will fail to load because they won't match the new enum value. - *Recommendation:* Should I keep the internal name of the job in the database consistent (perhaps by using a string identifier) or include a *Liquibase migration script* to update the corresponding rows in the database to match the new name. *fineract-loan/src/main/java/org/apache/fineract/portfolio/loanproduct/LoanProductConstants.java* - *Reason:* If these constants define keys for JSON API requests or responses, changing them will break existing API clients. - *Recommendation:* Should I follow the approach suggested in *FINERACT-2206*: keep the misspelled version as a *deprecated alias* (e.g., using Jackson’s @JsonAlias) while promoting the new "aging" spelling for future use. Thanks Yvana On Mon, 29 Dec 2025 at 12:05, 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 > >
