Tim Cross writes: > There are only two mechanisms by which org-mode is upgraded and as far > as I know, both require that the user either initiates the update or > turns on automatic updates. Your argument would be more compelling for > me if we were talking about updates which occur without user > intervention or control. In my case org is updated automatically. I use rolling release distros. There’s never a time when I say “now I get all the new versions, let’s look for breakage”. > Change is inevitable and such changes will from time to time, break > things. Is breakage truly inevitable? Do fundamentals of org have to change? If some small detail changes in a convoluted setup I have, that’s something I can cope with. That there are packages that almost never break and packages that almost always break on update, but little in-between sounds like most breakage isn’t inevitable. Here’s the source for the statement: https://stevelosh.com/blog/2012/04/volatile-software/ It makes my point much more succintly: ------ ------ ------ ------ ------ ------ When I'm updating a piece of software there's a good chance it's not because I'm specifically updating that program. I might be: - Moving to a new computer. - Running a "$PACKAGE_MANAGER update" command. - Moving a website to a bigger VPS and reinstalling all the libraries. In those cases (and many others) I'm not reading the release notes for a specific program or library. I'm not going to find out about the brokenness until I try to use the program the next time. ------ ------ ------ ------ ------ ------ and a second point: ------ ------ ------ ------ ------ ------ This may just be an artifact of how my brain is wired, but I actually get a sense of satisfaction from writing code that bridges the gap between older versions and new. I can almost hear a little voice in my head saying: "Mwahaha, I'll slip this refactoring past them and they'll never even know it happened!" Maybe it's just me, but I think that "glue" code can be clever and beautiful in its own right. It may not bring a smile to anyone's face like a shiny new feature, but it prevents many frowns instead, and preventing a frown makes the world a happier place just as much as creating a smile! ------ ------ ------ ------ ------ ------ > With respect to the current issue about line indentation. I think the > key question here is was communication of this change sufficient and if > not, what can be done to make such communication more effective. It cannot be made effective enough. If you make it effective enough, the other gazillion packages on the system will use the same mechanism and that will make it ineffective again. The only way that works is to avoid breakage on update — except for the few cases where it is truly unavoidable. We have the discussion here, because many people disagree with the notion that the current breakage was unavoidable. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken