publish current versions 5.0.1, 4.0.5 and 3.0.12

[level420]

I wanted to ask if it would be possible to publish the latest Firebird versions. Thank you so much in advance! Best regards.

[fdcastel]

Thank you, @level420, for the reminder. I will upgrade them ASAP.

[fdcastel]

@level420 I pushed a new set of images just now.

There are new tags now to run a specific version. E.g.

docker run --rm ghcr.io/fdcastel/firebird:5 firebird -z
docker run --rm ghcr.io/fdcastel/firebird:5.0.0 firebird -z
docker run --rm ghcr.io/fdcastel/firebird:4 firebird -z
docker run --rm ghcr.io/fdcastel/firebird:4.0.4 firebird -z

Sorry for the delay. As this is a fairly new project, I still didn't put up an automated way to update the images. But I intend to do it soon 😉.

Thanks again for the kindly reminder.

[level420]

@fdcastel thank you very much! Just pulled the images.

I've been using firebird for a long time, starting with version 1.5 installed directly on the host. Later, I switched to my own image with firebird 3 based on centos 7, then moved to @jacobalberty's firebird 3 image, and now I'm transitioning to using yours.

What surprised me was the need to run gfix -icu when switching from @jacobalberty's image to yours, due to the different ICU library versions used in images based on debian bullseye versus debian bookworm, which I never had to do before.

I don't know if this is worth mentioning in the Readme.md.

[fdcastel]

@level420 please wait a little bit more. 😅

I'm right now pushing an entire new set of images.

[fdcastel]

Done! All images are now published. You can see all tags in

https://github.com/fdcastel/firebird-docker/pkgs/container/firebird/versions

What surprised me was the need to run gfix -icu when switching from @jacobalberty's image to yours, due to the different ICU library versions used in images based on debian bullseye versus debian bookworm, which I never had to do before.

Whoa! That's a new one for me too.

Could you open a new issue with a minimal reproducible case? I didn't have this problem yet.

[fdcastel]

Could you open a new issue with a minimal reproducible case? I didn't have this problem yet.

Please, ignore. According to this comment this is by design.

Also, according gfix documentation:

Firebird uses the ICU library for some of its collations, and for indices on fields using those collations. When moving a database between different Firebird instances — without using backup and restore — and the destination Firebird instance uses a different ICU version, querying on fields with those collations or using those indices will fail. A similar situation can occur — on Linux — when an operating system update updated the ICU version, and Firebird uses the ICU version provided by the OS. Before Firebird 3.0, the only option was to back up and restore the database.

I would dare to say: always use a backup/restore cycle to move between different systems. That's probably why this one has never bit me 😅.

[level420]

The problem here on my test server was that I did not move to a different system, but simply replaced the docker image with yours, and restarted the container. So I replaced a firebird 3.0.11 image based on debian bullseye with a firebird 3.0.11 image based on debian bookworm. Same firebird version, thought this wouldn't make any issues.

[fdcastel]

So I replaced a firebird 3.0.11 image based on debian bullseye with a firebird 3.0.11 image based on debian bookworm.

I see your point.

However, from Firebird point of view, you actually DID move the database to "another system".

Debian bullseye uses libicu67 while bookworm uses libicu72. Albeit awkward, this is indeed the expected (and documented) Firebird behavior 🥹.

Just keeping the same Firebird version is not enough. The operating system (or, for better saying, its shared libraries) are part of the equation.