Hi Randy, A subject line more related to the matter being discussed would have been appreciated.
On Tue, 2023-07-18 at 20:40 -0400, Randy MacLeod wrote: > Does dmidecode follow semantic versioning (1) and Obviously not. We use 2-number versions, and this article assumes 3- number versions. > what does that mean for binaries that do not have an API? That's an odd question to ask here. Ask the person who wrote the article? > Was this release called 3.5 rather than 3.4.1 because an old feature > was dropped: > 3d68350 dmidecode: Drop the CPUID exception list No. It was called 3.5 because we use 2-number versions and the previous version was 3.4. No need to look for a hidden reason. > I don't have a pressing need for it but most of the commits in dmidecode > are to support new hardware and in an ideal world, those changes would > be back-ported to stable release branches. The world isn't ideal so any sentence starting like that is irrelevant by nature. There are no "stable release branches" for dmidecode, nor do I feel any need for that. It's a small project with a slow development pace. > I know that's extra work for the maintainer > but it would be interesting to know of that has been requested before and > what the conclusion was. What has been requested by whom, in what context? What kind of "conclusions" are you taking about? Every change is documented by its commit message. > Right now if I really need to support new hardware, with an old release, I'd > just backport the relevant > commits manually as other distros may already be doing. If you need to support new hardware then you'd rather update to the latest version of dmidecode. The code is simple and stable, risk of regressions is super thin, and known regressions are documented, so you can just backport a couple commits on top and you're done. The whole point of dmidecode updates is to support newer versions of the SMBIOS specification or new OEM types, so that's the bulk of the changes. If you want to backport all that, you obviously can, but that's more work with little to no benefit. > The context is a discussion (2) about what's a sensible approach to fixing > CVEs for dmidecode on a stable release in Yocto, and other distros I suppose. CVE fixes (or bug fixes in general) are a completely different topic. For fixes, you indeed want to backport the relevant commits. That should be fairly trivial in most cases. For your reference, commits which are known to fix serious bugs or regressions are listed by version at: https://www.nongnu.org/dmidecode/ in the Download section. If you think that some commits which should be listed there are missing, let me know and we can discuss it. All new versions of dmidecode also come with a comprehensive NEWS section. This should let you find out easily if there's anything you want to backport to your specific product. -- Jean Delvare SUSE L3 Support
