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