I don't want to spend much time discussing the node caching issue, as I've already weighed in. But there have been a number of responses that suggested I need to produce a list of 'broken modules' or suggestions that I'm FUDding the addition of caching. I'd like to explain in a bit of detail what my concerns are; if they're solved, so be it. If not, well, same deal. I just want to make sure that these issues are raised. There are a number of modules that it will definitely complicate things for (they'll have to learn a new way of managing data to avoid strange unpredictable 'stale data' bugs, and it ISN'T simply a matter of moving to view() operations on any sufficiently complex system). Obviously, developers can simply be told, "change your code, it's different now." My biggest concerns and frustrations are based on two things: 1) Judging from the issue itself, it went in without considering the impact on sites where high interactive traffic (voting on nodes, etc) would frequently reset cached nodes. In these situations, caching could easily make things WORSE, as nodes will rapidly be loaded, cached and cleared rather than simply loaded. The use of a 'nocache' param is certainly one solution, but it's an after-the-fact fix; it becomes the new, subtle, strange version of advanced caching's hook_init warning. "If you see something strange, maybe it's node caching." 2) It breaks existing APIs more than a month after the code freeze, __in a way that is NOT required to fix a critical bug__. It enhances performance in many cases, yes. But so would many API-breaking changes. I would have no problem with simply telling contrib authors to move their code to another op __if we were not past freeze.__ I've even argued for the addition of __non-breaking__ functionality post- freeze. But stopping breaking changes from coming in at the last minute is PRECISELY what the freeze is supposed to do. Do I think that the feature is fundamentally flawed? NO. Do I think that it went in without sufficient consideration of the varied activity footprints of high-traffic production sites? YES. I've said my piece, and I don't plan on dwelling any more on the issue. If others feel it's important (Morbus and Crell are two who've spoken up with concerns) they can do so. There are other important things to work on and I don't want to end up spending my cycles going back and forth on this particular one. If Dries and Goba decide to keep it and the concerns of others affected by it are quelled, so be it. I do think, though, that our very loose definition of code freeze (no breaking API changes unless required to fix a critical bug) should be revised. It should mean SOMETHING other than 'we think we're probably done breaking things, unless we come up with something cool.' --Jeff