For easier updates, can you provide tags like: major.minor

[williamdes]

And on each patch major.minor is updated

This also makes it possible for automatic updates using watchtower for example

[jbergstroem]

Just to clarify: aside from latest and 10.6.12, you are looking for 10.6? If yes, I like it.

[williamdes]

yes exactly, to have a latest but for a version range

[jbergstroem]

One thing to consider here is that Alpine doesn't maintain multiple versions of packages very long which means that leaning on 10.6 after the new LTS is chosen would likely make you go out of date unless there are serious critical security bumps. Also, renovatebot wouldn't track all versions of MariaDB in Alpine. I could consider adding git branches for minors and only bump for security updates which would likely happen once Alpine chooses the new LTS.

[williamdes]

do you mean that you only install the alpine MariaDB server package?
and everything will depend on alpine upstream?

[jbergstroem]

do you mean that you only install the alpine MariaDB server package?
and everything will depend on alpine upstream?

This is how the container works at the moment, yes! It's not necessarily a Bad Thing; most containers relies on distributions for dependency mangement. It just makes it harder to maintain multiple release lines.

That said, MariaDB doesn't encourage using non-LTS releases outside of their lifecycle which means that there won't be multiple supported release lines.

You can get an overview of all releases here: https://mariadb.com/kb/en/mariadb-server-release-dates/

MariaDB 10.11 will become LTS which means that 10.6 and 10.11 should overlap and likely exist in parallel for Alpine Linux release lines. Debian and most other linux distributions will do the same.

Some years ago I considered maintaining a custom build suite – the work is still in a branch – but its a lot of work to maintain a smooth cmake build experience across multiple versions. I could consider revisiting it at some point..

[williamdes]

yeah I understand all this, some companies can not upgrade because they are too afraid or such things
but I can upgrade, I was wondering why this repository was still on 10.6
can you provide newer versions?

[jbergstroem]

can you provide newer versions?

10.6 is the currrent LTS version which means its the one that is packaged in Alpine. As 10.11 becomes LTS, it will find its way here.

If I would undertake the mission of building myself, the repo probably would change significantly since its no tied to Alpine. At that stage it would likely be renamed and shaped into a new org with containers focused on size as the first goal (similar to this but without restrictions based on distribution).

[williamdes]

okay, so I think you could provide a lts docker tag so installations always track the lts version?

[williamdes]

by the way I do a bunch of containers at @sudo-bot so maybe you would want to join if you intend to do such a container
We have the the sponsored OSS level of docker registry: https://hub.docker.com/r/botsudo/capistrano

[jbergstroem]

okay, so I think you could provide a lts docker tag so installations always track the lts version?

This is what the latest flag would provide at the moment. I think the best option – as you suggested – will be adding a minor series (10.6). The problem with a "LTS" tag is that the LTS tags are overlapping (both 10.6 and 10.11 would have it). I could do what we set up with Node.js where lts would switch as part of a new LTS being promoted. Need to think about that.

My suggestion is – for now – to stick with latest which is 100% guaranteed to work and track latest LTS. As 10.6 lands (probs this weekend), feel free to switch.

[williamdes]

thanks for 10.6
the thing is by using latest you really do not know what version it will be if you don't update your config for one or two years
but now I know latest is lts ^^

[jbergstroem]

the thing is by using latest you really do not know what version it will be if you don't update your config for one or two years

Across Docker Hub I agree; there is no standardized/agreed upon best practice for latest. I personally stay off latest, so I guess I'm not dogfooding here :-)