Deprecating and removing unused HTML renderers

[Daniel Watford]

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

[Eugen Stan]

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
[phone] / netdava.com

[Jacques Le Roux]

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
>

[Jacques Le Roux]

Le 14/01/2021 à 15:43, Jacques Le Roux a écrit :
> We currently have 201 @Deprecated occurrences in Java classes (121 in 2008).
A large cleanup was done in with OFBIZ-6273

Jacques

[Daniel Watford]

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

[Eugen Stan]

On 14.01.2021 16:43, Jacques Le Roux 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
>

Removing after a release branch is created is reasonable IMO (when
"release created").

--
Eugen Stan
[phone] / netdava.com

[Nicolas Malin-2]

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 <[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
>>>
>

[Jacopo Cappellato-3]

On Thu, Jan 14, 2021 at 2:57 PM Daniel Watford <[hidden email]> wrote:
>
>[...]
> 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.

Thank you Daniel for the initiative.
I agree to deprecate in the branch 18.12 and at the same time remove
in trunk: in this way we will publish a few releases from 18.12 with
the deprecation warnings but the new release branch 21 (and the trunk)
will not contain the deprecated code.
Additionally, we can also remove, in the trunk and in the 18.12
branch, all the code that has been deprecated in 17.12 (or even
earlier).

Jacopo

[Daniel Watford]

Hi Jacopo,

The consensus seemed to be to only mark the renderers as deprecated in
trunk for the time being. These changes have already been committed.

Since marking code as deprecated would probably be classified as an
improvement rather than a bug-fix it wasn't appropriate to mark items as
deprecated in the 18.12 branch.

If direction from the dev community was to also mark the renderers as
deprecated in the 18.12 branch, I am happy to do so since it would expedite
the eventual removal of the deprecated code and make maintenance of sources
easier. However I imagine that there is a policy discussion which should be
had around deprecation in general and the impact of the number of branches
the project maintains.

Removing code that has been deprecated for a long enough period of time
from trunk might be a good task for the next Ofbiz Community Days event.

Thanks,

Dan.

On Fri, 15 Jan 2021 at 10:04, Jacopo Cappellato <[hidden email]>
wrote:

> On Thu, Jan 14, 2021 at 2:57 PM Daniel Watford <[hidden email]> wrote:
> >
> >[...]
> > 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.
>
> Thank you Daniel for the initiative.
> I agree to deprecate in the branch 18.12 and at the same time remove
> in trunk: in this way we will publish a few releases from 18.12 with
> the deprecation warnings but the new release branch 21 (and the trunk)
> will not contain the deprecated code.
> Additionally, we can also remove, in the trunk and in the 18.12
> branch, all the code that has been deprecated in 17.12 (or even
> earlier).
>
> Jacopo
>

--
Daniel Watford

[Jacques Le Roux]

Hi Daniel,

Inline...

Le 15/01/2021 à 11:21, Daniel Watford a écrit :
> Hi Jacopo,
>
> The consensus seemed to be to only mark the renderers as deprecated in
> trunk for the time being. These changes have already been committed.

Thanks, as you certainly know, I made a small amendment using a date rather than "Upcoming Branch"

> Since marking code as deprecated would probably be classified as an
> improvement rather than a bug-fix it wasn't appropriate to mark items as
> deprecated in the 18.12 branch.
>
> If direction from the dev community was to also mark the renderers as
> deprecated in the 18.12 branch, I am happy to do so since it would expedite
> the eventual removal of the deprecated code and make maintenance of sources
> easier. However I imagine that there is a policy discussion which should be
> had around deprecation in general and the impact of the number of branches
> the project maintains.

If we start a discussion (preferably not in this thread) I tend to agree with Jacopo, and you somehow.
We should keep things simple ans start afresh with R21.
Soon we will only support R18, R21 and trunk... Our resources are limited...

>
> Removing code that has been deprecated for a long enough period of time
> from trunk might be a good task for the next Ofbiz Community Days event.

We don't need to wait ;)

My 2cts

Jacques

>
> Thanks,
>
> Dan.
>
> On Fri, 15 Jan 2021 at 10:04, Jacopo Cappellato <[hidden email]>
> wrote:
>
>> On Thu, Jan 14, 2021 at 2:57 PM Daniel Watford <[hidden email]> wrote:
>>> [...]
>>> 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.
>> Thank you Daniel for the initiative.
>> I agree to deprecate in the branch 18.12 and at the same time remove
>> in trunk: in this way we will publish a few releases from 18.12 with
>> the deprecation warnings but the new release branch 21 (and the trunk)
>> will not contain the deprecated code.
>> Additionally, we can also remove, in the trunk and in the 18.12
>> branch, all the code that has been deprecated in 17.12 (or even
>> earlier).
>>
>> Jacopo
>>
>