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

[Martin Holmes]

I would suggest setting the validUntil date three months in the future 
for these long-deprecated things. That would mean:

  - Nothing could be expected to break ahead of this release, so we 
won't have any last-minute panics;

  - Things will start to break long in advance of the next release, so 
we will have time to work through the removal process with no looming 
deadlines.

Cheers,
Martin

On 13-06-20 02:55 AM, 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.
>>
>