The docker builds are provided as a convenience, just as the binaries are.
The official release processes are required by ASF as the custodian entity
for the project.  It would be more appropriate to have a better release
process so we can do this at least quarterly.

Please see my other thread about the need for build automation.

As for the tags on Docker, I do think Adam S could have provided more
discussion, but he dug into it and fixed something - that's the intent and
I trust that everyone understands the good intentions.

Moreover, the transparency that is now enabled is better than before.. and
having a cluttered set of tagging that has nothing to do with an actual
release is not useful, and from what I am reading may give a false sense
that each tagged build is somehow a "release".  They're not.  We cannot
pretend that they are.

The project can discuss how to use Docker, or not.

Again, the docker images are merely a convenience we do - not a release.
Let's aim to improve both.

On Wed, Sep 17, 2025 at 6:47 AM Arnold Galovics <
[email protected]> wrote:

> Hi Adam,
>
> Let's put back the tags as soon as possible. If somebody was relying on
> them, now their deployment might be broken (which again, disapproves the
> use of the community Fineract but further enhancing the importance of
> rather forking it).
>
> > *Here’s my perspective: even if we go back to producing Docker tags for
> each commit, any bugfix is always based on the latest develop branch
> anyway. In practice, there’s little difference between pulling the latest
> tag and pulling a commit-specific tag like
> a2c66e6c319e8c7b0e335d6d35d47c893abc353c (which, for example, contains the
> recent bugfix for FINERACT-2353). Both represent the state of develop at
> that time.*
>
> There's one fundamental difference though. Reproducibility. If a
> deployment is based on "latest" - let's assume a Kubernetes deployment/ECS
> deployment/even a simple docker compose deployment, a simple restart could
> produce a very different version then it was before. It's unsustainable.
>
> > *Also, it’s worth emphasizing that these builds are not official
> Fineract releases. They’re essentially snapshots of ongoing development,
> with the 1.x tags reserved for actual releases.*
>
> Agreed, they are snapshots. But the reason they are so important is
> because we - as a PMC - haven't defined any predictable, quick ways to
> reliably produce Fineract releases, hence people need to take this into
> their own hands and rely on "snapshots".
>
>
> To be honest, I'm really surprised this has been done without any
> preliminary discussion and analysis and was kind of a reckless move in my
> mind. Let's try not doing this in the future. Such a backward incompatible
> change - which could affect hundreds of deployments - must be discussed
> beforehand. Again, Adam, this is nothing against you, it's just one of the
> indicators that Fineract doesn't have such mature processes yet - which in
> turn and I keep repeating myself here, forces people to rather fork
> Fineract and do their thing in the fork.
>
> Best,
> Arnold
>
>
> Arnold Gálovics
>
> *CEO, Co-Founder*
>
> *+36 30 904 1885*
>
> https://docktape.com
>
> Docktape Technologies
>
>
>
>
> On Wed, Sep 17, 2025 at 3:37 PM Ádám Sághy <[email protected]> wrote:
>
>> Hi Arnold,
>>
>> Thanks for raising your concerns!
>>
>> Yes, the tags were removed. I was just about to share more context, as
>> Docker Scout has been enabled on the project, and with hundreds of tags the
>> visibility became really poor.
>>
>> Since we’re already on the topic (and I admit, a bit later than I should
>> have brought it up—my bad!), it’s worth discussing whether we really want
>> to create and maintain a tag for *every* commit on the develop branch.
>>
>> Here’s my perspective: even if we go back to producing Docker tags for
>> each commit, any bugfix is always based on the latest develop branch
>> anyway. In practice, there’s little difference between pulling the latest tag
>> and pulling a commit-specific tag like
>> a2c66e6c319e8c7b0e335d6d35d47c893abc353c (which, for example, contains
>> the recent bugfix for FINERACT-2353). Both represent the state of develop at
>> that time.
>>
>> Also, it’s worth emphasizing that these builds are not official Fineract
>> releases. They’re essentially *snapshots* of ongoing development, with
>> the 1.x tags reserved for actual releases.
>>
>> That’s the reasoning behind the cleanup, and I hope it clarifies my
>> thinking here. Of course, I’m open to further discussion if the community
>> feels strongly about commit-based tags.
>>
>> Best,
>> Adam
>>
>> On 2025. Sep 17., at 15:14, Arnold Galovics <[email protected]>
>> wrote:
>>
>> Hi Adam,
>>
>> Does this mean the "legacy" tags were deleted from DockerHub too?
>>
>> Why was removing the commithash-based tags deprecated and removed? I
>> don't think we had a discussion around this.
>>
>> Originally I was the one introducing the commit-hash based tags for both
>> Fineract and for the Mifos UI because what we all can agree on is that we
>> have infrequent releases.
>>
>> As long as we don't have a predefined release train for the next 6
>> months, preferably with monthly releases, I just don't see how anybody can
>> effectively rely on Fineract releases.
>>
>> Imagine you have a client who uses Fineract. There's a bug. You fix it,
>> open a PR, merge it to the develop branch and that's all. Bug is fixed,
>> nothing is released, the bugfix cannot be applied to your client since you
>> don't have an official release of Fineract which includes the fix. Waiting
>> for 6 months for a new release? Unrealistic.
>>
>> In my opinion this rather incentivizes forking Fineract completely and
>> never looking back. As long as we don't make it easy for clients to grab
>> the latest things easily (and "latest" is not an option, because it always
>> moves and companies want predictable things), we're pushing people off from
>> building a strong (client) community.
>>
>> Let me know if I misunderstood something.
>>
>> Best,
>> Arnold
>>
>> Arnold Gálovics
>> *CEO, Co-Founder*
>> *+36 30 904 1885*
>> https://docktape.com
>> Docktape Technologies
>>
>>
>>
>>
>> On Wed, Sep 17, 2025 at 2:54 PM Ádám Sághy <[email protected]> wrote:
>>
>>> Dear fellow Fineracters,
>>>
>>> We’ve recently reworked how Docker images for Fineract are published
>>> (thank you "Akshat-Soni02
>>> <https://github.com/Akshat-Soni02/Akshat-Soni02>”, “javamak”)  :
>>> https://github.com/apache/fineract/pull/4969
>>>
>>> https://github.com/apache/fineract/pull/5021
>>>
>>>  *Summary of changes:*
>>>
>>>
>>>    -
>>>
>>>    The latest tag now always points to the most recent build of the
>>>    develop branch (automatically updated with each push).
>>>    -
>>>
>>>    Versioned tags like 1.12.1, 1.12.0, etc. correspond to official
>>>    releases.
>>>    -
>>>
>>>    Legacy tags (e.g., commit hashes and other intermediate builds) have
>>>    been cleaned up.
>>>
>>> This maintenance was long overdue, and we hope the new structure makes
>>> it easier and clearer to use our Docker images.
>>>
>>> Please let me know if you are missing any “earlier” releases, and I will
>>> build and upload manually the missing versions.
>>>
>>> Best regards,
>>> Adam
>>>
>>
>>

Reply via email to