Re: Dmidecode 3.5 has been released

[Randy MacLeod]

Bonjour Jean,


On 2023-07-19 09:15, Jean Delvare wrote:
> 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.

Well, the third digit could be silent! ;-)

> >   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?

Sure, it' was only a question that I expected you to answer if you were 
aware of,
and following, the semantic versioning scheme.

> >   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.


That's what I expected but some people seem to think that the entire 
world has
switched over to semantic versioning.

> > 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.


Awww, that's one of my favourite ways of talking about how things should 
or could be!


> 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.


Understood and personally, I think that makes sense as well.

> > 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.

Sorry if I wasn't clear. I was asking you recalled other people asking 
for a stable branch of dmidecode
with backport to fix CVEs and support new hardware without dropping or 
adding features.

> >   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.

I agree but distro maintainers usually want to simplify life an still 
with a given release number.

> > 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.

Thanks for your timely and detailed response. I'll go back to the Yocto 
distro maintainers
with this information and see how they want to handle CVEs fixes and new 
HW support now that
you have explained how things work for this package.

Merci beaucoup!

--
# Randy MacLeod
# Wind River Linux