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.
