Rule #1–about public or shared code! Do not break compatibility without screaming to the world you are breaking compatibility!
<rant>
Better yet just do not break compatibility at all! We have been going over this since the days of COM (and earlier). I am working witih the very popular TweetSharp library and watching a tutorial video trying to follow along. These poor guys have moved classes and namespaces all over the place breaking almost every rule of compatibility in the book.
The problem with shared source or open source code all over the place is that you can really run into some poor coding practices on some of the smaller projects projects that rely on code that may be very popular for version 1 and 2, but when the development team abandon good software engineering practices all bets are off for the poor consumer trying to keep up with the documentation, code samples or versioning of the project.
In the end buyer (or should I say downloader) beware…
The problem with the TweetSharp guys is they are on their (at least 3rd iteration of moving things around and refactoring interfaces, breaking existing clients). This is not a good story.
</rant>
Comments
Anonymous
January 18, 2011
Rule #2-about libraries! Do not use immature libraries, unless you're willing to undergo some changes Rule #3-about agility! Be agile...Anonymous
January 22, 2011
grinAnonymous
January 22, 2011
Define immature? Rule #1 stands up regardless if the deployment is immature or not. The real pivot point is the fact it is released to the wild then it does matter if the library is 1 day or 10 years old. :-)