Hi,
I am all for getting rid of the extra "fat" ASAP.
Working on less code is easier.
Mark for 18 + remove in trunk sounds reasonable to me considering the
time differences.
Larger projects like Kubernetes have a deprecation policy:
- deprecate in release X
- keep in release X+1
- remove in X+2 or later depending on implications
Kubernetes does have a 4 month release cycle while OFBiz - once every
few years.
I think it's important to let people know when they will be removed so
they have some expectations.
If you deprecate them in 18 with a message that they are going to be
removed in trunk (next release) then it should be fine. People will have
6+ months to upgrade / find a solution which is reasonable IMO.
NOTE: I don't maintain OFBiz in production so I don't have to migrate
things.
On 14.01.2021 15:57, Daniel Watford wrote:
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
--
Eugen Stan
+40720 898 747 / netdava.com
