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