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

[Kevin Hawkins]

Okay, I have pushed back the values of @validUntil on deprecation of 
@targets on <alt>, <join>, and <link> to three months from now.  This 
will, I hope, fix the Jenkins build, and as Martin notes below, this 
will give time to work through the process properly.

On 6/20/13 8:25 AM, Martin Holmes wrote:
> 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.
>>>
>>