[tei-council] TEI deprecation practices

[James Cummings]

I've always viewed soft deprecation as an entirely unofficial 
form of deprecation. I.e. we're not yet stating that this is 
deprecated, we're just trying to remove active recommendations 
for its use. (i.e. making sure our examples use @ref instead of @key)

I believe that what Laurent recommends in a later message 
forwarded by Kevin is the deprecation procedure we agreed to 
previously. That when we decide to really really deprecate 
something, that we not only add a @status="deprecated" to it, 
remarks noting that it is deprecated, but open a ticket with the 
deprecated category on sf as a place to document and have 
discussion concerning it post-deprecation. That ticket should 
contain a date by which the object should be removed from the 
guidelines.

An example of where we've partly done this is @targets on 
alt/join/link but I've no recollection if we created a ticket 
concerning it?

-james




On 05/08/12 18:39, Martin Holmes wrote:
> HI Kevin,
>
> This is very helpful. The first thing that occurs to me is that the
> "soft deprecation" method is hard to notice in the Guidelines; the Note
> in which it's mentioned in e.g. <relationGrp> is right at the bottom of
> the page:
>
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-relationGrp.html>
>
> and many people would use the tag unknowingly without getting that far.
> The fact that <relationGrp> is no longer mentioned in the chapter linked
> from the element page is perhaps a clue, but not a very good one. We
> could make the deprecation more evident by putting some signal directly
> into the first row/cell of the element page (such as the red text shown
> in the hard-deprecated @targets definition).
>
> Personally, I don't like the distinction between hard and soft
> deprecation. What "soft" really means in the case of e.g. relationGrp is
> that the element is retained for backwards-compatibility; I think that
> should always be temporary, albeit perhaps long-lasting, and the
> end-result of deprecation should be eventual removal/replacement.
>
> Cheers,
> Martin
>
> On 12-08-04 01:42 PM, Kevin Hawkins wrote:
>> Councilors (cc'ing Laurent),
>>
>> I've been having some confused discussions with various people about
>> deprecation practices for the Guidelines, and I realized that I was not
>> even sure of our practice any more.  I've done lots of archeology in
>> meeting minutes and in Sourceforge and have produced what I think is a
>> summary of our deprecation practices, plus some questions:
>>
>> http://wiki.tei-c.org/index.php/Deprecation
>>
>> Please review.
>>
>> I hope once we sort this out, I will be able to move forward on
>> http://purl.org/tei/bug/3376456 , and it might also help James with
>> http://purl.org/tei/bug/3435326 .
>>
>> By the way, I've added a link to the wiki page from a new question and
>> answer I've just added to the Council FAQ:
>>
>> http://wiki.tei-c.org/index.php/TEI-Council-FAQ#In_what_ways_will_Council_break_backwards_compatibility.3F
>>
>> Thanks,
>>
>> Kevin
>>


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Research Support, IT Services, University of Oxford