Arnold Sure. In an ideal world, we would publish a new point release every month, and a Major release every year. Without the heroic efforts by Aleks and Michael we would not have had even ONE release per year from ~ 2016 until 2023. Having been the release manager a few times myself, I would invite you to also pitch in on a release, just to experience this process; it is highly convincing to want automation once you do that once. ;)
Maybe I mentioned this else-thread, but there is one project that I know of that is doing fully automated steps in getting to a probably done Apache release. If someone knows Gradle, then I think that is probably 40-80 hrs of work based on a conversation I had with them. Also Apache Tooling is working on a coding project - again all volunteer run - to create the process on Apache Infra, that properly abides by the Apache Software Foundation policy of "doing a release". Do you want to dive into that tooling and the other gradle project? I already started a thread and provided links. As for somehow "blessing" or "approving" unsigned artifacts on DockerHub - we have to say, "at the user's risk", and we are clear this is offered as a convenience. You may be correct about how people perceive those artifacts, I don't doubt that. But, there are sound reasons why I say that these do not carry the same weight from the PMC - it has to do with how we abide by regulations in the context of cyber security government policy, at least how I understand them. As I am also monitoring conversations about European working groups on the topic of open source stewards, SBOM security, CRA compliance, and so on, I think I know something here. We can, of course, do much better with DockerHub. As you may recall, last summer I took down the DockerHub images because they were TWO YEARS out of Date. So, it's not "someone else's job", it's "our job". Right? I think a clear advantage of using the DockerHub build is to make it clear that the project is active, that there are new features and new builds going on... it shows progress on a number of fronts. It is a positive move that took my time to get moving, and took a lot of other people's time too. Again, in an ideal world, the DockerHub artifacts should pass all of the tests and be ready for use. For that to happen, we need a lot more test coverage. As you know about the test framework, especially the cucumber tests, I would invite you to help define the process by which any Junior dev could write tests and enhance the test coverage - maybe some intro Jira tickets and a confluence page . While test coverage isn't a magic bullet, more of it would help to ensure that builds don't break things. I would invite you to the security list discussions as well. When we close CVEs, we have to have an officially signed release. (see also SBOM) That is the only way. Thanks James On Fri, Sep 26, 2025 at 7:23 AM Arnold Galovics < [email protected]> wrote: > Hi James, Adam, > > > We should aim for AT LEAST quarterly, predictable releases > No, I don't think that's the way to go. I understand that's the current > situation, but we should aim AT LEAST monthly releases. > > > So, right, what are the barriers? What improves the picture? What are > the next incremental steps to focus on getting it right? > Easy to grab artifacts for one. On top of the monthly releases, I'd still > propose to take every single commit as a release candidate version of > Fineract - since we have the very same testing, everything for a full > release and for each commit, since everything is automated. > We can mark those release candidate versions as they are not signed, > didn't go through the whole full release process but other open source > projects can easily publish snapshots. I don't see why we couldn't and > shouldn't. Btw questionmark here, why can't we sign the snapshot releases? > > I'd ask back here, what's stopping us from doing this? What are the > roadblocks? > > > Arnold, do we know for sure removing the legacy tags will affect many > deployments and drive folks away from our (quarterly or better) official > releases? I'm skeptical. Why aren't they speaking up? > Well Adam, many Fineract customers are not speaking up, simply because > they are not on the mailing list. In fact, if you think about it, if > somebody forks Fineract (for good reason apparently), they just won't > follow Fineract's lifeline anymore (at least not frequently). > > > > Re: reproducibility -- yes, reproducibility is a Good Thing, but I > disagree that legacy tags improve reproducibility. A sysadmin shouldn't > rely on unofficial images always being available, and we shouldn't lead > them to believe they would be. I assumed they were just a convenience for > testing/demos/PRs. > I was mostly reflecting on the fact that using "develop"/"latest" is not a > good idea because it's not reproducible. On the other hand, a sysadmin > should absolutely rely on images published on the apache/fineract > dockerhub repo. Frankly speaking, unless you're heavy in regulation (i.e. a > bank in the EU, or a lending SME of some sort), you just don't care whether > an image is signed or not. Just as you start up a PostgreSQL container in > Docker, I doubt you double-check whether that version is officially signed. > > On the other hand you are contradicting yourself (again, nothing personal > here). If you assume it's just for testing/demos and things like that, > imagine the situation where you prepare a demo with fineract:latest 3 days > in advance and a restart makes it so latest now means the very last commit > in Fineract which breaks your demo. Well, I'd say that's a pretty big issue > when evaluating the viability of a solution. Not a good look. And again, > back to reproducibility. > > > And sorry for the delayed response, busy week for me. > > Best, > Arnold > > > Arnold Gálovics > > *CEO, Co-Founder* > > *+36 30 904 1885* > > https://docktape.com > > Docktape Technologies > > > > > On Wed, Sep 17, 2025 at 9:05 PM Adam Monsen <[email protected]> wrote: > >> My reaction to Ádám's message starting this thread was +1, "whew, >> finally!" because this is what I expect and hope to see from images on >> Docker Hub: tags aligned with official releases, and a "latest" tag. >> >> Arnold, do we know for sure removing the legacy tags will affect many >> deployments and drive folks away from our (quarterly or better) official >> releases? I'm skeptical. Why aren't they speaking up? >> >> Agreed we should discuss big decisions, but I feel like this was done >> properly and I'd generally prioritize continuous improvement and lazy >> consensus above discussing/permission. >> >> Re: reproducibility -- yes, reproducibility is a Good Thing, but I >> disagree that legacy tags improve reproducibility. A sysadmin shouldn't >> rely on unofficial images always being available, and we shouldn't lead >> them to believe they would be. I assumed they were just a convenience for >> testing/demos/PRs. I considered using them, but it was easy to build my own >> jars/wars/images so I didn't bother. >> >> Arnold, good point that sometimes a sysadmin needs a particular >> feature/fix not part of an official release, and yes, we try to keep the >> build passing on the develop branch, but do we guarantee any of this? >> Should we? Are there other/better ways we could support sysadmins needing >> to do this? For example, 1. a Docker image that builds Fineract >> images/jars/wars reproducibly, 2. instructions on how to both leverage an >> official release and include a feature/fix you need, 3. something we >> already have/do (custom modules?) Just spitballing here, but surely we can >> come up with some creative solutions. >> >> What if an unofficial build has a feature/fix a sysadmin *cannot* have, >> and they also don't want exactly what's in an official release? They're >> back to forking anyway. I think our best option with the resources we have >> is continuing to improve the release process based on input from >> deployments/community. >> >> James, +1 to your questions and ideas about the release process. I think >> that's a good start. I can kick off the next release whenever we're ready >> (using the current process -- and it should go faster than last time save >> the necessary delays for voting and such). >> >> Recent release history, for posterity: >> >> *version* *release date* *resources* >> 1.12.1 July 28, 2025 wiki >> <https://cwiki.apache.org/confluence/display/FINERACT/1.12.1+-+Apache+Fineract>, >> github <https://github.com/apache/fineract/releases/tag/1.12.1>, email >> <https://lists.apache.org/thread/zd9z5prxt9qbv5xrkj2xy5s6o0nvzk7y> >> 1.11.0 March 9, 2025 wiki >> <https://cwiki.apache.org/confluence/display/FINERACT/1.11.0+-+Apache+Fineract>, >> github <https://github.com/apache/fineract/releases/tag/1.11.0>, email >> <https://lists.apache.org/thread/jn00ybtg148rqxno9sr1qdg0cqxktoht> >> 1.10.1 December 30, 2024 wiki >> <https://cwiki.apache.org/confluence/display/FINERACT/1.10.1+-+Apache+Fineract>, >> github <https://github.com/apache/fineract/releases/tag/1.10.1>, email >> <https://lists.apache.org/thread/1o4gtv54dhpv96kslgj3hhvpn8mp1stn> >> >> One more thought re: tags -- we might add, for example: "stable", "1", >> and "1.12", etc. in addition to "1.12.1", if anyone wants/needs these. >> >
