Hi Michael,
Thanks for mentioning this which came already on the table several times.
We had this discussion in the past[1] (the last one?). But AFAIK only about
services and came to this agreement[2]
[1] https://markmail.org/message/gqultbcgbonph5ax
[2] https://s.apache.org/12Uq
I don't remember if we took a decision about how handling Java code.
Your proposition for Java seems the same idea but with longer time. Quoting
Nicolas
<<We tag code deprecated as a part of a release and these code will be removed
from next release.>>
Please review [2], a consensus would be needed about 1 or 2 releases before removing from code. I expect the same rule for all the code (services or
what not).
From my side I see no urge to remove and 2 releases after deprecation fits with
me, ie your proposition here.
Beside generalising, we maybe need to state a clearer rule at [2]...
Thanks
Jacques
Le 11/05/2019 à 09:48, Michael Brohl a écrit :
Hi Mathieau,
We had a discussion about deprecation in the past, I currently do not have the
time to dig it out.
I think we should start annotating @deprecated with the date/release branch when it was introduced. User should have at least time over 2 releases
to move from the old to the new implementation.
In this example, we would introduce the deprecation in trunk, so it will first be "visible" for users in release 19.x. We can then remove the
deprecated code after the 20.x branch was created.
We should also start to track the deprecatations and consequently remove deprecated code when its time (see above). Currently there are some
depretations for years, with no tags when they were introduced so we can get better at this.
Just wanted to throws this in for a first feedback, more later.
Thanks for your work!
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 10.05.19 um 17:53 schrieb Mathieu Lirzin:
Hello,
I have opened the ticket OFBIZ-11019 which deprecates a method in the
‘org.apache.ofbiz.security.Security’ interface (see rationale in the
JIRA ticket). If nobody disagree in the meantime, I will commit the
attached patch in a week.
With OFBIZ-11019, near half of the declarations of that interface are
now deprecated which is a symptom a poor initial design. As a
consequence I think it is time to consider re-designing a new interface
to superseed ‘org.apache.ofbiz.security.Security’.
In order to achieve a better design, it would help if people currently
implementing ‘org.apache.ofbiz.security.Security’ outside of the
framework could describe their use-case and requirements.
If nobody step-up, It will consider that as a sign that this extension
mechanism might not be useful anymore and could be removed.
Thanks in advance.
[1] https://issues.apache.org/jira/browse/OFBIZ-11019
