Hi Daniel,
Quite a good question, we had similar discussions before.
An old one is https://markmail.org/message/rlksriqjznsndq2g
The end of last one is https://markmail.org/message/4aia3v5ugjjajmhf
It's documented for services at https://s.apache.org/6ophi
We currently have 201 @Deprecated occurrences in Java classes (121 in 2008).
Apart by looking for revision information, in Java code we miss the date when
the deprecation took place.
I answered to David's proposition in the 1st thread above
<<I will vote for "just after the release is created".>>
If we agree that "release created" means creation of a new release branch (and not releasing a package which would be confusing for packages inside a
release branch), we could, as suggested recently,
1. create a R21 branch
2. Remove all the currently deprecated methods in the trunk (and not yet in
R21?)
3. Document this process in in the same place than above in the wiki
4. Use this process for each new release branch created
What do you people think?
What about not removing in trunk before creating R21 as I believe most
deprecations are old if not very old ones?
Jacques
Le 14/01/2021 à 14:57, Daniel Watford a écrit :
Hello,
https://issues.apache.org/jira/browse/OFBIZ-11927 refers to HTML renderers
which do not appear to be used anymore. James has confirmed this
observation.
I assume that we only need to keep the unused classes around in case they
are being used by a third party plugin, but we can at least mark them as
deprecated so that any such plugin authors might notice.
My question is what should the timing be for deprecation and removal?
My assumption would be that we can mark the HTML renderer classes as
deprecated in both trunk and the release 18 branch asap.
But when should we remove the unused HTML renderers? Is it okay to remove
them from trunk at the same time as marking them deprecated in release 18?
This would ensure they are removed from whichever release is planned to
follow 18.
Thanks,
Dan
