From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547944992 kernel-5.11.0-155 kernel-5.11.0-156 kernel-5.11.0-157 kernel-5.11.0-158 These are tags by an autogenerated by scripts and have nothing to do with dist-git because most of them were not used. Of those, only kernel-5.11.0-155 was built for rawhide, with an extra build of 156 for F34. The rest of them were never in dist-git at all. `<N>` does distinguish the actual tag applied and is useful there. The date is useful in being able to quickly see when a build was last done, or more importantly to distinguish quickly if a script failed and ark-latest does not have a valid new build. As we build rawhide almost daily, and in the morning, I can tell you what I build in dist-git today was in Linus' tree yesterday most of the time. There is a 1 day difference in most cases. It is static, and as a maintainer it is much more useful as a representation of when the tree was built vs when linus handled a pull request. Remember, this date doesn't necessarily correlate with when I generate dist-git so much as when ark-latest is composed in practice. It has happened several times that I don't get to a build until the next day, but before the script runs. By the time that finishes koji, it looks like a fresh build, but it is probably time to start the next one because that was older. Developers are doing various things from os- build, but from a maintainer standpoint, dist-git is only generated from ark-latest. As to whether `<N>` remains where it is, or is moved to between the 0 and rc, I just don't care all that much. The reasons for keeping it at the end are, it seems more logical with the build number being at the end, as versioning gets more granular from left to right. It also falls into the "if it ain't broke" category in that it has been there for a good 10 years now, and I don't see any particular advantage to changing it. But in the end, it doesn't really make a ton of difference to me. Perhaps some of the ELN developers and maintainers would have stronger opinions there as they have a *lot* more tooling around completed builds than Fedora does. _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
