Nothing is ever easy in life. The release of 4.6.0 and the subsequent release of 4.6.1 proved that. 4.6.1 was primarily concerned with fixing a couple of very nasty bugs from the 4.6.0 build. The two worst bugs included a breaking change to the behavior of ModuleSettingsBase and a defect in the UserSettings page that caused the system to overwrite your usersettings whenever someone logged in. Unfortunately, when we attempted to roll back the changes to ModuleSettingsBase to the pre-4.6.0 code, we did not get all of the relevant code rolled back. This only made the breaking change worse. This prompted us to take the unusual step of completely removing the 4.6.1 download until we could get a new version coded, tested and built to put back online. Last night we posted the new 4.6.2 version which fixed the breaking change.
One of the lessons learned as we went through this exercise is that when building an API you must be constantly evaluating how your audience might use that API. Often your customers may do things you never intended, but which you should have anticipated. We need to strive to develop our APIs, not for how we intend to use them, but for how we anticipate our customers will want to use them. Maybe I only need an add and an update method for some entity. Should I create a delete method as well since it is likely that customers will need that feature? This analysis affects not just what methods or properties I make available, but also how I architect the class hierarchy. Finally, we need to be very careful and deliberate whenever a decision is made to remove a public member of an API. It doesn't matter if we never use that portion of the API. If it is public, then there is a good likelihood that someone will have found it and started using it in their code. One of our overriding goals from day one has been to avoid breaking changes wherever possible. We try to batch up breaking changes that are needed to evolve the platform and only introduce those changes in a single large release every 2 to 3 years.
The decision to remove the properties from ModuleSettingsBase was wrong. Unfortunately, the architecture was not as clean as it should have been which meant rolling back the change was not straightforward as it impacted other parts of the system. This also meant that a clean fix was also not possible. The system has been patched to correct the initial bug which precipitated the change and to correct the rolled back code so that it works as expected. We will likely revisit this portion of code in the future to clean up the inheritance chain so that this portion of code is not so brittle.
Technorati Tags:
DotNetNuke