You can find more examples of that kind of puffer if you go to a website's cookie consent pop-up and find the clause after "we use cookies to...".

I’ve long thought that those “this new version fixes bugs and improves user experience” patch notes that Meta et al copy and paste on every release shouldn’t be permitted.

Tell me about it. I look at all these random updates that get pushed to my mobile phone and they all pretty much have that kind of fluff in the description. Apple/Android should take some steps to improve this or outright ban this practice. In terms of importance to them though I imagine this is pretty low on the list.

I have dreamed about an automated LLM system that can "diff" the changes out of the binary and provide some insight. You know give back a tiny bit of power to the user. I'll keep dreaming.

It's worse, as someone who does try to privide release notes I'm often cut off by the max length of the field. And even then, Play only shows you the notes for the latest version of the app.

Slack's Mac app release notes [1] rotate a few copy pastes, here's the one that shits me the most.

> We tuned up the engine and gave the interiors a thorough clean. Everything is now running smoothly again.

Yeah nah mate, if every release is the first release where everything is running smoothly, I'm not going to believe it this time either.

Makes me wonder if the team has some release quota to fill and will push a build even if nothing meaningful has actually changed.

[1] https://slack.com/release-notes/mac

Ugh. That's especially annoying because they're trying to be hip with slang and use a metaphor that requires cultural knowledge that you can't really assume everyone has.

I made a library where version 2 is really really much faster than version 1. I'd want everyone to just move to version 2.

But then you are saying a specific great new feature, performance, and not just the claim and concept performance, but numbers.

I'm sure they actually had new features…

What are they specifically?

I don't know how you can be missing the essence of the problem here or that comments point.

Vague claims are meaningless and valueless and are now even worse than that, they are a red flag.

Please don't tell me that you would accept a pr that didn't explain what it did, and why it did it, and how it did it, with code that actually matched up with the claim, and was all actually something you wanted or agreed was a good change to your project.

Updating to the next version of a library is completely unrelated. When you update a library, you don't know what all the changes were to the library, _but the librarys maintainers do_, and you essentially trust that librarys maintainers to be doing their job not accepting random patches that might do anything.

Updating a dependency and trusting a project to be sane is entirely a different prospect from accepting a pr and just trusting that the submitter only did things that are both well intentioned and well executed.

If you don't get this then I for sure will not be using or trusting your library.

Yeah... RISCV routine was put in, then some binary test files were added later that are probably now suspect.

don't miss out on the quality code, like the line that has: i += 4 - 2;

https://git.tukaani.org/?p=xz.git;a=commitdiff;h=50255feeaab...

> some binary test files were added later that are probably now suspect

That's confirmed

From https://www.openwall.com/lists/oss-security/2024/03/29/4:

> The files containing the bulk of the exploit are in an obfuscated form in

> tests/files/bad-3-corrupt_lzma2.xz

> tests/files/good-large_compressed.lzma

> committed upstream. They were initially added in

> https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf...

It probably makes sense to start isolating build processes from test case resources.

Sure but then you can smuggle it into basically any other part of the build process…?

FWIW, "4 - 2" is explained earlier in the file:

  // The "-2" is included because the for-loop will
  // always increment by 2. In this case, we want to
  // skip an extra 2 bytes since we used 4 bytes
  // of input.
  i += 4 - 2;