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 >>>> >>>>
