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

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

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.

The Project Team that manages the specification (think "expert group") should decide what specification-defined APIs or features to deprecate and when.

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.

The Project Team that manages the Jakarta EE "platform" specification (think "platform expert group") should decide what included components to deprecate and when.

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.