[tei-council] respond by 1 May: summary of and path forward for "no longer recommended" and "deprecated" practices

[James Cummings]

I'm with Sebastian and Gaby's second paragraph here.  I'd say 
since we're introducing this deprecation feature to set any 
legacy ones to be something like 2013-12-11 just to test our 
features etc.

Does that mean if something ends up fully deprecated and its 
validUntil is just a day before release date that we need to have 
removed it before release?  That is good but also means that when 
we freeze for release we need to check that nothing deprecated is 
occurring is only valid until slightly less than the next couple 
weeks. :-)

-James


On 20/06/13 10:55, Gabriel Bodard wrote:
> What are those handful of things overdue for deprecation? I bet hearing
> about them might convince some of us they're better killed sooner than
> later! :-)
>
> (If not, should we put everything at least six months in the future from
> now, to give our new procedures and tests time to take effect?)
>
> G
>
> On 2013-06-20 05:40, Kevin Hawkins wrote:
>> On 4/19/13 11:27 AM, Kevin Hawkins wrote:
>>>> On 4/19/2013 6:47 AM, Gabriel Bodard wrote:
>>>>> On 2013-04-19 09:42, Sebastian Rahtz wrote:
>>>>>      b) we can automate the check in 3. of the wiki page. i.e. don't
>>>>> ask people to go grepping, but instead add to the build checks so
>>>>> that a validUntil which is less than 6 months away from todays date
>>>>> generates a warning and a validUntil which is after todays date
>>>>> generates an error. This will cause Jenkins to fail the build if we
>>>>> ignore a validUntil date.
>>>>>       c) for 1 B, i would suggest a formal process whereby the release
>>>>> notes have a section listing all the Specs waiting on death row, with
>>>>> their date. so we write a script
>>>>> to generate a section for inclusion in the notes. anything which cane
>>>>> be automated, lets automate...
>>>>
>>>> Agreed. Neither of these means that no human has to look at the
>>>> deprecation and take an action (meaning that decisions can and will be
>>>> reviewed), but they also help to make sure we don't lose sight of things
>>>> we've planned to do or people we should have warned.
>>>
>>> Sebastian's idea is a good one.  I've noted in the wiki.
>>
>> While implementing those past deprecations according to our policy, I
>> set some @validUntil dates that are in the past.  These yielded
>> Schematron errors that cause Jenkins to fail, so it appears Sebastian
>> implemented something he suggested back in April.
>>
>> If everyone is satisfied with the way this is working and feels that
>> we've given enough notice for deprecation on these (despite not having
>> Schematron warnings as part of our releases for the past two years) I
>> suggest we actually go ahead and remove these deprecated things.
>>
>> K.
>>
>


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