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