Gilles Sadowski wrote: >>>> These deprecations should go in the 2.x branch. Version 2.2 will be >>>> cut from the 2.x branch, so in order for users to see the >>>> deprecation annotation, it needs to be there. >>> I hesitated to leave the deprecation indication, the more so that the >>> mentioned "IterativeAlgorithm" does not exist yet! >>> The issue is far from clear; see >>> https://issues.apache.org/jira/browse/MATH-413 >>> >>> This interface should probably disappear (or go into some other package) but >>> some classes still depend on it (in package "analysis.solvers"). >>> >> That's fine. We don't have to decide this yet. The point that I >> was making is that what we should be doing to show intent to remove >> things in 3.0 is to add the deprecation annotations to the 2.x >> branch. That way, users will see the deprecation in the 2.2 release. > > Then, we should agree on the way to go (e.g. for MATH-413) *before* the > release of 2.2 so that we can add deprecation warnings in all the classes > that might disappear as a result of the refactoring towards 3.0. > It would be ideal to get all deprecations into 2.2; but I don't personally see it as strictly necessary - i.e., we could either cut a 2.3 including more deprecations or remove/replace some things in 3.0 without having deprecated them in 2.x at all. Major releases can include compatibility breaks. Deprecation is a good way to give users heads up when we know something is going to be removed or replaced. Our policy should be that as soon as we have decided to remove or replace something in 3.0, we should deprecated it in the 2.x branch. We should not; however, postpone the 2.x release until we are 100% certain about all incompatible changes that we are going to make in 3.0. I am interested in other views on this.
Phil > > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
