I maintain a couple libraries for other people. After having gone through a couple releases for each of them, there are some things I would do differently, if I had to do them over again.
The question is: Should I do them over? I guess we all face that dilemma - how to balance the helpfulness of the maintenance activity versus the disruptive effects of change.
Obviously for bugs, the change is imperative. No dilemma there. For new features, it is a question of utility versus added complexity. I feel comfortable dealing with that question.
It is the fuzzy space between bugfix and new feature that I'm asking about. One example is maintenance to comply with framework design guidelines or CLS compliance. For one library, I wrote it without thought of CLS compliance, and then people asked for it. As a result I had to modify the interface to swap uint out for int. That is a disruptive change, for little gain (for most people).
Another issue: FxCop compliance. I had to make changes in param names for some methods, to make FxCop happy. But those changes really only affect people using reflection - the types did not change, only the names of the params.
The issue I'm dealing with right now is: framework design guidelines. The guidelines regarding events say that events ought to have a signature with two arguments: (Object source, EventArgs e). But I was absent that day in my Framework Design course ;). The events in my library currently take only a single EventArgs argument.
I am now adding new events to the library. Should the new events follow the framework design guidelines? or the pattern already established in the library? If I use the design guidelines for the new events, should I modify the existing events to also comply with the design guidelines? And if so, how to do the migration? Should I use the [Obsolete] attribute? How many releases?
More generally, I'm interested in thoughts on maintenance in this fuzzy area between bugfix and new feature.