Posted by
Daniel Watford on
Jan 14, 2021; 3:03pm
URL: http://ofbiz.116.s1.nabble.com/Deprecating-and-removing-unused-HTML-renderers-tp4763776p4763786.html
Thanks Jaques,
After reading the later messages in the thread you posted, and revisiting
the Commiter guidelines you linked to I think the steps for deprecating the
HTML renderers become:
1 - Mark classes as deprecated in trunk only. I've since been reminded that
we would only backport bugfixes to release branches so it makes sense that
deprecations should only apply to trunk.
The classes will be marked with deprecated since="Upcoming Branch"
2 - When a new release branch is taken from trunk the release manager will
amend for 'deprecated since' marking.
For example, if the next release is R21, the classes will be marked
'deprecated since="R21"'.
3 - New jira ticket raised to remove the deprecated services on trunk where
deprecated since != "Upcoming Branch"
So for OFBIZ-11927 the only action is to mark the classes as deprecated in
trunk. All other 'cleanup steps' can be triggered following creation of the
next release branch.
Thanks,
Dan.
On Thu, 14 Jan 2021 at 14:45, Jacques Le Roux <
[hidden email]>
wrote:
> 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
> >
>
--
Daniel Watford