Refactoring libraries
During the development of a shared library it may happen that the external
interface has to change, for example by renaming a method. This is of course
easy to do with a Rename refactoring. (Obviously, stable version of
libraries
shouldn't be changed like this.)
The problem is that any projects that use this library are now out-of-date
and have to be manually fixed. One solution is to have all these projects
added as modules to the library project. This may not always be feasible.
Another solution would be to bundle up these changes and have a mechanism
that could apply these changes to the affected project. Something like a
shelved change but on a higher level.
Does something like this exist? Does it sound possible to implement, or
would there be too many weird cases?
/Mikael
Please sign in to leave a comment.
I was always taught to never change a public interface. Once it gets into the wild, you no longer have control. You can mark it deprecated and remove it down the road.
How about deprecating the methods and adding @see to point them to the new method. Then when the library is compiled against, the other projects can update their code at their leisure. Wait a version or 2 before the deprecated method is deleted.
If you have complete control of the library and the users of the library, then add the modules for the other projects to your library project, make your changes, commit to your repository, then remove the modules that are not part of the library project.
Much as it pains me to say it, Eclipse has this. I've never felt the need, myself.
--Dave Griffith
This can be taken too far.
The story is that the inventor of make realized that the syntax was bad, but felt that he couldn't fix it because he already had 10 users.