> > Ugh, I update my emacs package pretty infrequently and I usually have 30 or > > more packages updating at a time -- I can't see wading through 30 NEWS > > files searching for landmines... > > > > Yes, this I think is a problem. Most of those packages probably only > have minor changes and bug fixes. We really need some way to be able to > sort or grade those packages based on whether they are minor or major > upgrades. Some sort of metric which would let you gauge the amount of > change and decide if checking the NEWS file would be advisable.
An aside. This is one of the reasons that I generally oppose breaking up repositories into smaller projects. Some users want more frequent updates to some parts of a codebase, but they are usually outliers. The end result is that splitting the repo pushes more and more work onto the users, most of whom receive no benefit since they are not bleeding edgers, because now it is up to them to determine compatibility, read the NEWS, etc. Sometimes deeper coupling can actually help. For example in this thread if Emacs and Org were more tightly coupled in their releases then the changes to electric indent mode might not have gone through at all, or might have been delayed until Org could coordinate the change so that users only had to deal with it once. Do we actually want Org and Emacs development to be more coupled? Probably not, but I suspect there is a systematic bias on the part of more frequent participants to want greater decoupling because they are often engaged in the development process and thus have a skewed perspective on what is important --- namely to make development easier.
