In general we try to keep the CiviCRM developer interface with CiviCRM as stable as possible. Ideally hooks, payment processor extensions and api calls should change as little as possible between releases.
In every release there are some improvements and additions. Generally the place to find out about these is the api change log - ie,
http://wiki.civicrm.org/confluence/display/CRMDOC/API+changes
Unintentional changes can also happen. Our first line defence against these is the unit test suite. Basically if something is tested then with very few exceptions it should continue to work. So, if you want your code to be stable - get to know our tests!
Very very occassionally we make intentional changes to api behaviour. In 4.6 I have changed the behaviour of relationship api so that it will no longer fail if you try to update the contacts on an existing relationship. This error doesn't seem to have any real logic and causes pain. See https://issues.civicrm.org/jira/browse/CRM-15786
A more notable change affects payment processors - if you write payment processors you should take a look at https://issues.civicrm.org/jira/browse/CRM-15555 and https://issues.civicrm.org/jira/browse/CRM-15714
In a nutshell in 4.6 it is possible to override form interactions with payment processors in the payment processor class - including declaring the fields to display, the validation to do, and even to override the whole payment form buildForm.
There is however, one change that 'could' be unexpected. The $form object used to be a property of the payment processor class. In 4.6 the payment processor is a property of the form - so this circular logic had to be removed. I cannot think of any situation where accessing the form object from the payment processor would be useful - but perhaps you could & did? if so please add your input here or on the ticket.
Comments
Hey Eilleen,
What is wrong with circulair logic in objects? If you have a property referring to the form on the payment processor and you have a proptery payment processor in the form class then you have an interface to both objects in your code which could be sometimes quite powerfull. So that payment processor example contradicts your example of stable programming interfaces.
I agree that sometimes you cannot think of any good logical use case and that it form that point of view could be valid to remove something.
Thanks any way for this post and the good work you are doing!
Jaap
The problem occurs when the form is serialised & cached to the civicrm_cache table - it starts to crawl the recursion
That problem could be solved by implementing a __sleep and __wakeup function in your php objects. See http://php.net/manual/en/language.oop5.magic.php#object.sleep
Hmm - interesting. I'll give that a read through