Hello Daniel, Fully agree to follow you proposal.
Nicolas On 14/01/2021 16:03, Daniel Watford wrote: > 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 <jacques.le.r...@les7arts.com> > 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 >>> >
