You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current version strings are really long and hard to parse at a glance. Can we maybe add some delimiters to make them easier to parse?
For example just adding periods would help a lot to easily identify the day of the build
20260925000509 → 2026.09.25.000509
In our package builds we use + to separate out revisions
20260925000509 → 2026.09.25+000509
Can we strip the millennium?
20260925000509 → 26.09.25+000509
How granular do we really need these seconds to be? There's only 86400 seconds in a day right so we're like into miliseconds in granularity or we have a leading 0?
20260925000509 → 26.09.25+00509
If we could parse it down to minutes that would nice since it takes more than a minute to build and upload:
If there's technical reasons we can't/shouldn't do this in the build system, I'll move this to system settings and then just in the client parse it out to something a bit more digestible
There was an earlier note that the mkosi (or something) requires the file format to be a certain way (ARCH, DATE) but if it is really the case, can the file not be renamed to whatever format(s) are required for parsing and/or uploading to the user-facing public download website (stable/daily) after the build succeeds?
The version string and the file names have to match, and they both pull from the same place, so this does change the filename. You can see this on this comment with builds named elementaryos-9.0-proposed-x86-64.26.09.25+1506.iso and elementaryos-9.0-proposed-arm64.26.09.25+1504.iso
The only gotcha is that 26.09.25 sorts below 20260925001520 because 20260925001520 > 26, but that's a one time nuke of the daily bucket and a new install to get working again.
Ah jeez I wonder if we should just nuke the 9 altogether. It looks funny now to have 9.0 and also 26.09.25. I feel like the like 9.0 loses meaning here
Activity
danirabbit commentedon Sep 25, 2026
If there's technical reasons we can't/shouldn't do this in the build system, I'll move this to system settings and then just in the client parse it out to something a bit more digestible
vjr commentedon Sep 25, 2026
There was an earlier note that the mkosi (or something) requires the file format to be a certain way (ARCH, DATE) but if it is really the case, can the file not be renamed to whatever format(s) are required for parsing and/or uploading to the user-facing public download website (stable/daily) after the build succeeds?
danirabbit commentedon Sep 25, 2026
@vjr sorry to be clear this is about the version string that is reported to sysupdate, not about the file name
lewisgoddard commentedon Sep 25, 2026
The version string and the file names have to match, and they both pull from the same place, so this does change the filename. You can see this on this comment with builds named
elementaryos-9.0-proposed-x86-64.26.09.25+1506.isoandelementaryos-9.0-proposed-arm64.26.09.25+1504.isoThe only gotcha is that 26.09.25 sorts below 20260925001520 because
20260925001520 > 26, but that's a one time nuke of the daily bucket and a new install to get working again.danirabbit commentedon Sep 25, 2026
Ah jeez I wonder if we should just nuke the 9 altogether. It looks funny now to have 9.0 and also 26.09.25. I feel like the like 9.0 loses meaning here
vjr commentedon Sep 27, 2026
Should have posted my two (or is it four?) cents in this issue ticket instead a PR so linking them here, please excuse any notification noise:
#886 (comment)
#886 (comment)
#886 (comment)
#886 (comment)