In order for people to be comfortable with development of code based on your project and not have to constantly worry about the rug being pulled out from underneath them, we have instituted the following policy. Our goal is to take this matter as an extremely serious practice.
The amount of time between deprecation and removal must be at least one release of your project. It could be more than one version release before the deprecated item is removed, but it cannot be less than one version release. In other words, we can deprecate something in 2.1 and remove it in the release of 2.1.1. The amount of time between 2.1 and 2.1.1 could be measured in days, not months. Discussion will occur on the mailing list pertaining to the real number of versions between deprecation and removal. You will have a chance to express your concerns and we will take them into consideration. Most likely a major feature change will not be removed between a 2.1 and 2.1.1 release. Instead, we would wait until 2.2 to remove the deprecated items in that case.
The reason why we do not feel that time is of importance is because 6 months may not be a long enough time for a project to keep up and 2 weeks might be fine for another project. By focusing on deprecation through releases, people can choose to code against a specific version of your project and feel comfortable that their code will compile for at least one released version. This also gives people the chance to compile against various previous releases to do incremental upgrades and find out what will break in the next release.
When changing the signature of a public or protected method or class, this has the potential of breaking someones code who depends on the method or class. Since we are developing Open Source software, there is absolutely no way we can tell if someone is using our code or not. Therefore, in order to minimize the effect of changes, it is possible to use the concept of deprecation. When working on code, keep in mind the following guidelines: