...With our deprecated block we have another mean to lead the user to the new components. When it's excluded the application will just not work. But I don't know if this is true for 2.2 and real blocks too...
hmm...I don't like the idea of moving code around to deprecate it, what if a block has just one component that must be deprecated?
Also, with CVS we lose code history when moving files around.
Marking components with a marker interface would be less disruptive and easier to undo if (when) mistakes happen.
Then the component manager could trigger log messages or exceptions (depending on the "strict deprecation" setting) when initializing the component.
So alltogether:
a) Components that are just renamed or replaced with only sitemap changes (FileGenerator => XMLGenerator, DirectoryGenerator => TraversableGenerator (or however it is called ;-) ), StreamGenerator => XMLGenerator + ModuleSource) are deprecated in 2.1 and removed in 2.2....
ok but I agree with Carsten that renaming just because names aren't optimal does not make much sense.
b) Components that need "real" application changes as processPipelineTo or anything similar are also deprecated in 2.1, but will be kept in 2.2.
ok
c) Deprecation messages:
Strict deprecation for a) components. 80% are catched by "file" => "xml" and "file" is the default generator and "xml" will be it.
Loose deprecation with a warning on every usage (otherwise they are to easily lost in the logs) for b) components. If we also use strict deprecation here, we don't really need b).
I was more thinking about a global "strict deprecation" setting, defaulting to false at first, but global. Either you leave it false to be able to use all components (with warnings) or you set it to true if you want to make sure your app doesn't use any deprecated stuff.
-Bertrand
