Dmitry Kornilov wrote on 05/18/18 01:56 PM:
- Marking
old and unused technologies
as optional or deprecated is good. We probably need
to define a deprecation
policy. Is that us? Or, the Spec committee?
I think it’s us, but I am not sure. Sometimes I still have
problems understanding who is responsible for what, but it’s
getting better.
Me too! Here's my current view...
A Project Team should decide what product-specific features to
deprecate and when.
Fine.
The Project Team that manages the specification (think "expert
group") should decide what specification-defined APIs or features to
deprecate and when.
Fine.
The PMC should provide guidelines for deciding what to deprecate and
when. Project Teams should follow those guidelines unless they have
a good reason not to. I'm not clear on who gets to approve a
release for a project, but that seems like the time and place to
arbitrate disputes over deprecation. Perhaps it should be possible
to appeal to the Steering Committee.
PMC is approving releases.
The Project Team that manages the Jakarta EE "platform"
specification (think "platform expert group") should decide what
included components to deprecate and when.
Fine.
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.
— Dmitry
|
