I have added a git repository for the NewCommandProcessingInfrastructure, as described in my previous email. This is the link https://github.com/NewCommandProcessingInfrastructure/finance/tree/main
On Sun, Oct 5, 2025 at 10:52 AM Kapil Panchal < [email protected]> wrote: > The Apache Software Foundation’s ecosystem is a remarkable collection of > projects, each representing deep expertise in its own domain. Yet, what > remains elusive is a cohesive workflow that connects the entire software > development lifecycle — from the origination of an idea, to its design and > implementation, to its use in production, and finally to the measurable > impact it creates for the users. > > The *New Command Processing Infrastructure* emerges as a unifying pattern > that brings order to this fragmented landscape. Represented through an > extensive UML model (attached herewith), it abstracts the complexities of > command orchestration into a structured yet adaptable framework. This > pattern is not merely a design construct — it represents an evolution of > thought, where patterns transcend their traditional boundaries and evolve > into *architectural frameworks* and *foundational libraries*. > > This work aspires to be recognized as the *24th Design Pattern* in > continuation of the GoF lineage — not for novelty, but for necessity. It > formalizes a pragmatic approach to command execution pipelines, combining > *pre-processing*, *execution*, and *post-processing middleware* to enable > reliability, observability, and event-driven extensibility at scale. > > Beyond its technical depth, this effort symbolizes a bridge between two > parallel universes — *academia* and *development*. While academia defines > frameworks of understanding, development transforms them into frameworks of > utility. The missing link between these worlds lies in structured research > — journal papers that record, analyze, and preserve such work for both > scholarly and industrial progress. > > The Apache Foundation’s openness to research attribution provides an > opportunity to place this work where it belongs — at the intersection of > *research, > design, and development*. By consolidating developer personas — from the > research-oriented who thrive on theoretical insights, to the > management-oriented who seek tangible outcomes — this initiative cultivates > not only a methodology, but a *work culture* rooted in reflective > innovation. > > Following the successful collaborative rollout of the Command Processing > Architecture with logical design teams, this work is intended for formal > publication under the *Data Structures and Algorithms (cs.DS)* category > on *arXiv.* > > Just as a teaser, I have attached herewith what the paper would look like. > > > PS: I would need help publishing a paper on arXiv (it's free). It needs > previous researchers to approve the release of this work. > > > On Fri, Oct 3, 2025 at 10:42 PM James Dailey <[email protected]> wrote: > >> Kapil >> >> Please start new threads when appropriate. >> >> Interesting ideas, and a good target. Perhaps you would like to dig into >> the apache release process and the github repos I referenced before. >> >> https://www.apache.org/legal/release-policy.html >> >> see github/ tooling-actionblob/main/readme >> https://github.com/apache/tooling-actions/tree/main/release-on-atr >> => release-test.apache.org >> >> and see Grails release process (mostly) automated --> >> https://github.com/apache/grails-core/blob/7.0.x/RELEASE.md >> >> Review and then come back with a set of actions and coding for Fineract. >> >> Thanks, >> >> >> On Fri, Oct 3, 2025 at 8:18 AM Kapil Panchal < >> [email protected]> wrote: >> >>> I think what is the need of the hour is to have a *Release Alignment >>> Strategy*. Do we have a release plan that coincides with the release of >>> all major dependency releases? e.g. Java releases its LTS every 3 years >>> around September? SpringBoot follows a rough release cycle of 6 month with >>> releases every May and November? A nice to have would be a plan that >>> follows these major releases. It also makes it more credible, dependable >>> and gives confidence of a matured and stable product? >>> >>> On Fri, Oct 3, 2025 at 12:49 PM Ádám Sághy <[email protected]> wrote: >>> >>>> Hi James, >>>> >>>> I dont disagree, but we have a couple way too early work. >>>> >>>> Let me give a try to find a commit which is the most “reliable”, maybe >>>> cherry pick a little. >>>> >>>> Regards, >>>> Adam >>>> >>>> On 2025. Oct 2., at 18:37, James Dailey <[email protected]> wrote: >>>> >>>> Hi Adam - Thanks. >>>> >>>> Today might be a good day to grab a commit point for the release. >>>> AFAIK, the devs have finished some features as of yesterday and pushed some >>>> additional clean up commits. There is always dev going on, so the task is >>>> not to find the "perfect" point but one where the features are working well >>>> enough for 90% of the users. I think that point is today. >>>> >>>> Does anyone disagree? >>>> >>>> >>>> On Mon, Sep 29, 2025 at 2:44 PM Adam Monsen <[email protected]> wrote: >>>> >>>>> Thanks James. I'm happy to do this and I'm ready to start whenever. >>>>> >>>>> https://fineract.apache.org/docs/current/#_releases outlines a >>>>> roughly 17-day process, so I'd expect the same for this release. >>>>> >>>>> *I need advice on when's a good time to start the process, and which >>>>> commit to start from for the release branch*. @Ádám Sághy >>>>> <[email protected]>, would you please advise? >>>>> >>>>> Release process streamline idea: We can branch for the release from >>>>> any point we choose, so if we happen to have a known good commit (has all >>>>> the right/complete features, none we don't want, and all tests passed) >>>>> already, maybe we could use it as-is and shorten the release branch >>>>> stabilization time. I'd guess the chance of this is small. >>>>> >>>>> re: automating the release process: Yep. This needs more/dedicated >>>>> ideas/research/testing. >>>>> >>>>> On Fri, Sep 19, 2025 at 3:32 PM James Dailey <[email protected]> >>>>> wrote: >>>>> >>>>>> I’ve asked Adam Monsen to again be the release manager - we have some >>>>>> issues to get into an official release. Can we get this out by Oct 7th? >>>>>> >>>>>> We are seeking to make the release process more streamlined and >>>>>> automated as well. >>>>>> >>>>>> As part of this we will likely roll release 1.12.x to end of life. >>>>>> Some important improvements like oauth changes cannot be backported. >>>>>> >>>>>> >>>>>> >>>>>> >>>>
