Breaking Changes

Developer
Jul 14, 2008 at 3:03 PM
Would anyone be opposed to adding features between releases, in an ad-hoc manner, that might cause breaking changes down the road? In other words, would you rather wait for features to ensure that the existing interface does not change? Or would you rather get the features now with a good chance that the interface will have to change as more features are added? Is there some balance that we could strike?

I've been slow to add certain features because I'm not sure what the best api would be.

Thanks!
Jul 15, 2008 at 8:07 AM


yorkrj wrote:
In other words, would you rather wait for features to ensure that the existing interface does not change? Or would you rather get the features now with a good chance that the interface will have to change as more features are added? Is there some balance that we could strike?

The UserControl I created around the HTML Editor that is then used by our programmers requires only a minimal set of properties to function:
- .Text (in-out of the HTML)
- .ToolbarSet (we alllow the programmer to select from a 'default' or an 'Extended' toolbar menu set)
- .Width/.Height (in case its not 100% of the container control)
- forcing the UI language (internal to the UC, not set by the programmer)

So as long as the above are available any changes to the interface should not matter.