Followup-For: Bug #931566 Control: tag -1 experimental IMHO, the intention behind this change is good. The implementation was completely untested. Well, it's kind of hard to properly test such a change. The documentation is not really helpful.
I initially thought this was caused by my rather complicated setup. Until I experienced it on a machine installed with buster two weeks ago and not yet "customized" by me. Multiple errors like this: E: Repository 'http://security-cdn.debian.org stretch/updates InRelease' changed its 'Suite' value from 'stable' to 'oldstable' N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details. apt-secure(8) says: INFORMATION CHANGES A Release file contains beside the checksums for the files in the repository also general information about the repository like the origin, codename or version number of the release. This information is shown in various places so a repository owner should always ensure correctness. Further more user configuration like apt_preferences(5) can depend and make use of this information. Since version 1.5 the user must therefore explicitly confirm changes to signal that the user is sufficiently prepared e.g. for the new major release of the distribution shipped in the repository (as e.g. indicated by the codename). OK, and what do I do now? How do I confirm that? It took me some time to discover --allow-releaseinfo-change in apt-get(8). Andreas PS: my apt pinning is exactly setup to prevent unwanted release changes even if sources.list contains everything from wheezy to experimental ;-)
