Adam, Thanks for starting this thread. My thoughts inline..
On Thu, Oct 9, 2025 at 1:30 AM Adam Monsen <meonk...@apache.org> wrote: > For those who missed today's community call > <https://cwiki.apache.org/confluence/display/FINERACT/2025-10-08+Meeting+notes> > with > some stake/interest in our releases, I wanted to welcome your > discussion/feedback on what I presented today about release engineering. > This will inform future work (including mine). Note the in-progress > release <https://lists.apache.org/thread/30w4xo1snl8o9nlkg2rd48d0pc7n5q0x> > will continue per the existing process > <https://fineract.apache.org/docs/current/#_releases>. > > Here are my notes from the meeting, and you can also find the recording > online > <https://app.fireflies.ai/view/Fineract-Community-Call::01K6X2TZJXGCAQWMXWA48F7VMD> > (trying to get that downloaded as well). > > - > > goals for releases > - > > ( consider these value-driven goals first, then get to > improvements, ideal frequency, automation ) > - > > stable, reliable, frequent, well-documented > - > > avoid vendor lock-in, leverage open source, release from any > platform > - > > reproducible? non-goal, for now > <https://lists.apache.org/thread/b9f1lyxnxz9dvvhoo31yzlm82obcs569> > > Goals: The second point is great imo, because quality should be our top driver. Culture wise as an Open Source project, the 3rd bullet point makes sense. Talking to frequency, I think TDD approach would help where we write tests _before_ we write the feature and also increase test coverage. Also automation that is mentioned below also helps greatly. > > - > > current > - > > complex and manual > - > > robust and inefficient > - > > large codebase, gradle tasks, project & roadmap management, ASF > policies > > Talking to large codebase, complex and manual process, will it help ease the process with shared responsibilities to ensure build of individual components which are the source of JAR files: - fineract-accounting-<version>-SNAPSHOT.jar - fineract-avro-schemas-<version>-SNAPSHOT.jar - fineract-branch-<version>-SNAPSHOT.jar - fineract-core-<version>-SNAPSHOT.jar - fineract-document-<version>-SNAPSHOT.jar - fineract-investor-<version>-SNAPSHOT.jar - fineract-loan-<version>-SNAPSHOT.jar - fineract-savings-<version>-SNAPSHOT.jar If an assistant helped with say half of these, would it help ease the process of release, or the assistant took up some responsibilities? I'm willing to chip in since I have experience in Docker, Software packaging, Shell scripting and DevOps process automation, besides coding. > > - > > proposed and in-progress work and other notes > - > > understand, simplify, standardize, automate > - > > test/evaluate ATR (Apache Trusted Release) tool > <https://lists.apache.org/thread/767n32q7dnwkm5mrdoqtq4yf3bqy7sb4> > - > > policy/culture improvements to ease releasing > - > > keep develop clean: be careful with WIP code/features > - > > maintain your issues > - > > improve documentation and release plugin, or shift to other > automation > - > > we don’t currently maintain releases, vendors could do this > - > > what is ideal release frequency? depends on type of fix … we may > need/want to differentiate between major, minor, patch/hotfix releases > (e.g. full ceremony doesn’t make sense for a hotfix) > > Agree on the last point. -Terence. > -- > Adam Monsen > Software Engineer ~ Mifos Initiative > Apache Fineract Release Manager > PGP key id 0xA9A14F22F57DA182 > >