mkosi.bump: format version string

[danirabbit]

Fixes #885

Outputs version string like 26.09+251701

[github-actions]

Installer builds for b29fd7b

Do not use these installers for production systems. They are intended for testing purposes only. They will update to the latest PR build, which will break your install eventually.

Arch	ISO	Checksum
amd64	elementaryos-9.0-proposed-x86-64.26.09.25+1506.iso	sha256
arm64	elementaryos-9.0-proposed-arm64.26.09.25+1504.iso	sha256

[danirabbit]

Oh I guess it does change file name. Does that matter?

[lewisgoddard]

Yes, it breaks updating existing daily installs #885 (comment)

It's fine so long as we're okay with breaking dailies.

[danirabbit]

let’s draft this for a second to think it through

[github-actions]

Installer builds for b20d868

Do not use these installers for production systems. They are intended for testing purposes only. They will update to the latest PR build, which will break your install eventually.

Arch	ISO	Checksum
amd64	elementaryos-proposed-x86-64.26.09+251705.iso	sha256
arm64	elementaryos-proposed-arm64.26.09+251705.iso	sha256

[github-actions]

Installer builds for e5176b7

Do not use these installers for production systems. They are intended for testing purposes only. They will update to the latest PR build, which will break your install eventually.

Arch	ISO	Checksum
amd64	elementaryos-26.09+251939-proposed-x86-64.iso	sha256
arm64	elementaryos-26.09+251937-proposed-arm64.iso	sha256

[github-actions]

Installer builds for 253eefb

Do not use these installers for production systems. They are intended for testing purposes only. They will update to the latest PR build, which will break your install eventually.

Arch	ISO	Checksum
amd64	elementaryos-26.09+252025-proposed-x86-64.iso	sha256
arm64	elementaryos-26.09+252024-proposed-arm64.iso	sha256

[lewisgoddard]

This might cause problems in the future because our MatchPatterns in mkosi.images/sysupdate/mkosi.extra/usr/lib/sysupdate.d/20-uki.transfer look like this:

MatchPattern=elementary_@v_%a+@l-@d.efi \
             elementary_@v_%a+@l.efi \
             elementary_@v_%a.efi \
             elementary_@v+@l-@d.efi \
             elementary_@v+@l.efi \
             elementary_@v.efi

@v+@l might read version as 26.09 and 251937 becomes boot tries left. That would break updates by comparison for the month.

We might want to drop options 4 through 6 in that snippet.

[jumpyvi]

Suggested change

	date -u +%y.%m+%d%H%M
	date -u +%y.%m_%d%H%M

We shouldnt use + here, it doesn't have to be underscore, but let's not use anything sysupdate might extend.

[vjr]

Can you not just use a minus instead of an underscore here? It will look consistent in other places like the ISO file name elementary-os-proposed-x86-64-20260927-134251.iso.

[vjr]

Actually, as I was trying to convey/suggest in my comments #886 (comment) and #886 (comment), why not just keep the "full" version without any special chars, so it's like 20260927134251 as a source of truth, then other places can extract/split whatever they need based on this core format, so if you want to just show elementary OS 26.09 in the system settings plug operating system view or name the ISOs elementary-26.09.27-134251-arm64.iso, or even (I'm about to open a ticket for this hah!) set the systemd-boot menu text like elementary OS daily (2026-09-27 134251) you're free to reformat whatever way you like.

[danirabbit]

Someone on social media brought up reproducible builds. In this vein, what do we think about just year and month for stable and only including the day/time for daily and proposed?

[vjr]

Someone on social media brought up reproducible builds. In this vein, what do we think about just year and month for stable and only including the day/time for daily and proposed?

@danirabbit i think you should always include the full build version string (like 26.09 270739) i mean keep as much detail in the core mkosi.bump file and you can pick and choose what you want in later stages of the build and in other places like system settings plug operating system view.

it's especially important even for stable builds because (if my understanding isn't wrong) you're no longer pulling package updates directly from apt/flatpak (ubuntu archives or appcenter/flathub remotes) but only deliver to users via image builds (off your R2 or whatever) so what i'm trying to say is even for stable builds/images you might need to build new images (new version strings) as frequently as multiple times on the same day for scenarios like urgent bug/security fixes either in elementary components/packages or external sources like apt/flatpak (ubuntu archives, appcenter/flathub remotes), right?

[vjr]

in fact, if im reading the chatter on discord/github tickets right, why not keep the version string even more detailed and group the date and time together (not attach the day to the time) - meaning instead of 26.09+270744 (aka YY.MM+DDHHMM) just take it to the max like a typical build timestamp 2026.09.27 074634 (aka YY.MM.DD HHMMSS) so it looks like what a user might expect and not be confused by the day/date being attached to the HHMM portion?

leave the mkosi.bump fully detailed (with or without the plus sign, i think someone commented it might affect things like systemd-boot if theres a plus in the image name, for boot retry attempt counting?) and then format it (exclude whatever you don't want) in other places.