Re: [ee4j-pmc] Jakarta EE / EE4J Technical Vision document

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

Dmitry Kornilov wrote on 05/19/2018 02:14 PM:
>> Someone (the PMC?  the Platform Project Team?) needs to decide whether
>> "deprecate" means "removed immediately", "marked as do not use", "marked in
>> release X and removed in release X+1", or something else.  Having everyone
>> use a different definition of "deprecate" is not a good thing.
>
>
> "marked in release X and removed in release X+1” this is what I have in mind.
> Spec Committee must define what “deprecated" means for specs. Project Team
> decides what “deprecated” means for their project. There could be
> inconsistency in “deprecated” meanings in different implementations. I am not
> sure that we can standardise it.
>
I can imagine that it might be beneficial for there to be one set of rules for
specs and a different set of rules for projects for how they handle
deprecation.  I can't imagine that there's some great advantage in every project
"innovating" on the definition of "deprecate".  If a project wants to do
something that doesn't match the PMC-defined approach for deprecation, they
should just call it something else (e.g., "retirement", "removal",
"abandonment", etc.).  The PMC can decide whether that's acceptable when they
review the release.