Hacker News new | ask | show | jobs
by Rendello 13 days ago
It might be worth bringing this up on the forum [1]. The developers are quite active there, and it's possible they've never considered this option, or they have considered it and have reasons to not go for it. The original design followed Postel's Law (see my comment from the other say [2]), it would (theoretically) be nice if that mess could be avoided by specifying an edition.

Today I noticed I could do `pragma foreign_key = ON`, and despite the pragma being wrong (it should be foreign_keys, plural), it reported nothing. In fact, it reports nothing with the correct pragma either. So check your pragmas!

1. https://sqlite.org/forum/forum

2. https://news.ycombinator.com/item?id=48900625

1 comments

The Postfix mailer has allowed recommended default behavior to evolve using its "compatibility_level" parameter:

https://www.postfix.org/postconf.5.html#compatibility_level

https://www.postfix.org/COMPATIBILITY_README.html

You get a warning whenever you depend on the deprecated old default until you either move forward or specifically commit to the old behavior.

I think CMake actually has the best default evolution system out there (a bit surprising give how awful the actual language is).

Each "policy" they change can be manually set to old or new, and there's a global config to set them all at once based on the version of CMake.

https://cmake.org/cmake/help/latest/command/cmake_minimum_re...

I scarcely go a week without encountering issues caused by their huge CMake 4 backward compatibility break. I think CMake has one of the worst solutions out there.
Hasn't been an issue at all for me, but in any case that's a separate issue. They removed compatibility with CMake earlier than 3.5, which is 10 years old at this point. Support length is orthogonal to default behaviour evolution systems.
I never encounter things which need CMake <3.5 features. I constantly encounter things which declare their "minimum supported version" to be below 3.5.

Which makes a lot of sense for those projects! They can be built with CMake 3.2 because they don't need anything introduced in a newer version, so why not declare 3.2 to be the earliest supported version? It's not their fault that CMake interprets "minimum supported version" weirdly?