I think they mean the "refactoring" should be shipped as part of the release to be applied by codebases depending on the library, possibly automatically or semi

I think they mean the "refactoring" should be shipped as part of the release to be applied by codebases depending on the library, possibly automatically or semi-automatically That's exactly what I'm talking about! For example, in the StORE version control that comes with VisualWorks Smalltalk, it would be fairly easy to detect the presence of a particular class and method, whose name contains metadata about version, then pop up a window showing the potential refactorings. The go equivalent would be to have a dist-refactorings subdirectory, and a go tool. Maybe dist-refactor? go dist-refactor ... The refactoring scripts would have names that contain version information. Invocation of dist-refactor would cause a list of available refactoring scripts to be applied to the codebase from all of the dependencies that are at a version later than the one compiled. Alternatively, one could invoke go dist-refactor [library]