[tei-council] Next TEI-C Guidelines Release (presumably 2.6.0)

[Martin Holmes]

On 14-01-07 10:19 AM, James Cummings wrote:
>
> I think holding off on announcing to TEI-L until we write the
> release notes makes sense, I hadn't thought of that. I've added a
> blank readme-2.6.0.xml so please do add changes you think are
> important (or we should draw people's attention to) to that.
>
> So, is it consensus that we stay in an 'unstable' state with
> regard to the schematron warnings?

With the caveat that some of us must keep checking through those 
warnings as we get closer to release, to make sure there aren't any new 
ones that actually require action.

Cheers,
Martin

>
> -James
>
>
>
> On 07/01/14 18:00, Martin Holmes wrote:
>> On 14-01-07 09:45 AM, Syd Bauman wrote:
>>
>>>> This also means that I will be announcing the pending release to
>>>> TEI-L soon. I've changed the version number to 2.6.0beta as of
>>>> revision 12749.
>>
>> Once we're in beta, we should be asking on TEI-L for public proofing of
>> the Jenkins versions, and also the readme should be done, IIRC, so
>> people know what changes they should be proofing.
>>
>>>>      *Before I announce this what needs to be done to make the P5-test
>>>> job stable?* We should do that first.
>>>
>>> Can it be made stable? Now that we have Schematron warnings for
>>> @validUntil constructs that are still exemplified, I thought we were
>>> stuck with unstable.
>>
>> For this build, we are, unfortunately, but I really don't like this as a
>> long-term thing. I think it's a priority to get our act together wrt
>> deprecation and warnings before the 2.7 release.
>>
>> One option, which is time-consuming but which could work, is for
>> Sebastian and/or I to add explicit suppression of the known schematron
>> warnings for deprecated constructs to the Jenkins log parser. We could
>> do this as new deprecations are added, then after every release we would
>> go through the log parser and remove any suppressions which are obsolete
>> (because they have transitioned from warnings to errors because the
>> expiry date has gone by, or because the constructs have now been removed
>> and the warnings/errors are no longer being generated). It seems a bit
>> heavy-handed but it would work. I definitely don't like the situation
>> where we "live with" unstable builds; that will cause us to stop
>> investigating warnings and miss new ones that might appear.
>>
>> Cheers,
>> Martin
>>
>
>