Description of problem: Release date missing for a product – Fedora CoreOS Stable – which has been released. Version-Release number of component: libosinfo.x86_64 1.8.0-5.fc33 $ osinfo-query -f short-id,version,release-date,eol-date os vendor="Fedora Project" version="Stable" Short ID | Version | Release date | End of life ----------------------+----------+--------------+------------- fedora-coreos-stable | Stable | | For comparison: $ osinfo-query -f short-id,version,release-date,eol-date os vendor="Fedora Project" version="33" Short ID | Version | Release date | End of life ----------------------+----------+--------------+------------- fedora33 | 33 | 2020-10-27 | silverblue33 | 33 | 2020-10-27 |
This is not so simple, and that's the reason we mark it as "rolling". For instance, let me invite you to my train of thoughts here. * Problem: CoreOS Stable doesn't have a release date. * Solution: Add a release date for CoreOS Stable. * Process: * Check the official web page, looking for such information: https://getfedora.org/en/coreos?stream=stable * There you realise they do a few releases per month; * Shall we use the date of the very first release? * Matthew Miller made an announcement on June 20th 2018 about the project, see: https://fedoramagazine.org/announcing-fedora-coreos/ * This date would still not be accurate; * Shall we update the entry for every new release? * That's not going to happen, we can't do that, do a libosinfo release, and expect it to reach the distros before it becomes outdated * Takes ~15 days for a package to reach Fedora, for instance. * Understanding better the problem: * I think you're asking for the release date to be filled up because you want to achieve something else. What's that something else you want to achieve? * A guess, from my side, the root cause of the problem is that we `osinfo-query os` doesn't return any information about the release-status. * Would something like the example below help to solve your usecase? ``` fidencio@quino ~/src/upstream/libosinfo $ ./build/tools/osinfo-query -f short-id,version,release-date,eol-date,release-status os vendor="Fedora Project" version="Stable" Short ID | Version | Release date | End of life | Release status ----------------------+----------+--------------+--------------+---------------- fedora-coreos-stable | Stable | | | rolling ``` If so, please, let me know and I can go ahead and provide the patch to the project.
JFTR, I went ahead an opened https://gitlab.com/libosinfo/libosinfo/-/merge_requests/110, as I think this is good to have, regardless.
That's a pleasure to read a comment so well argued. That "not so simple" was worth mentioning indeed. A good deduction – "want to achieve something else" – as well. Since I conceived each Fedora CoreOS edition observes the same rule as Fedora Server regards to life cycle – which is fixed with an accuracy of one month – this led me to expect to know the release date in order to calculate the date of end of life, which would eventually be also the date i would have to schedule an acquisition of a new OS image.
(In reply to ricky.tigg from comment #3) > That's a pleasure to read a comment so well argued. Thanks! :-) > Since I conceived each Fedora CoreOS edition observes the > same rule as Fedora Server regards to life cycle – which is fixed with an > accuracy of one month – this led me to expect to know the release date in > order to calculate the date of end of life, which would eventually be also > the date i would have to schedule an acquisition of a new OS image. So, no, that's not exactly the case. Fedora CoreOS will be doing rolling releases of their ISOs / OS images every single time a new ostree is generated on their side. Sometimes it'll lead to two, three new images a month. Sometimes it'll lead to two, three new images a week. It's really expected, from Fedora CoreOS concept, that users don't have to reinstall a new system, but rather upgrade the current image to the newer one. For more info, please, refer to: https://docs.fedoraproject.org/en-US/fedora-coreos/auto-updates/ With everything discussed here, do you think we could consider closing this issue as "NOTABUG"? Last but not least, Ricky, thanks for the quick answer!
That sounds fair. Thank you in general, and for the link.
(In reply to ricky.tigg from comment #5) > That sounds fair. Thank you in general, and for the link. Thank you for using our project! We've added support to get whether a project is a rolling distro to libosinfo (https://gitlab.com/libosinfo/libosinfo/-/merge_requests/110), and I'll also do a backport of that to the Fedora packages. Also, please, feel free to also file issues in our gitlab, I tend to check those more frequently.