[tei-council] how to release errata, versions etc

[Lou Burnard]

Sebastian Rahtz wrote:
> Christian Wittern wrote:
>   
>>  It all depends on many things, for example, how frequently we want to 
>> release.  If we have, say, a release once per year that would mean 
>> there would be both changes to the wording and schematic changes.  
>> Frankly, I am not sure if we should release more frequently.
>>     
> well, yes, this is what I want us to decide and say publicly how
> we will work.  Whether its  "release as soon as  see an error"
> or "release on November 1st every year regardless", I don't
> mind, but we should commit to a methodology.
>
> If I had to vote, I'd probably go with a fixed 6-monthly
> release cycle.
>
>   
My views are as follows:

a. attractive tho the idea is, I still don't think we can reliably 
distinguish "text only" changes from "schema-affecting" changes.

b. moreover, if we tried to formalise the distinction by having a 
separate fork, we would have the problem of keeping the two branches in 
parallel wrt the purely textual changes (dont want to have to make typo 
fixes in two places)

c. we have a constituency which embraces both the rabidly in touch with 
the bleeding edge mentality and the slow-and-steady-as-she-goes; it 
would be good to keep both happy if possible

d. we should in general be slow to make schema-affecting changes unless 
there is a strong consensus in favour of them or that the current 
situation is badly broken

So I propose the following mechanism

1. Changes (of whatever kind) are made in SF as and when agreed. We tell 
people who want to see the next version befiore it is released that they 
can get it from there.

2. Obviously erroneous typos and inconsistencies which dont affect 
schemas get fixed immediately in SF.

3. Errors which do affect schemas do NOT get made immediately, but are 
put into TRAC. Six weeks before a release date we announce that we are 
going to implement the stockpiled collection of error fixes, and request 
any further corrections  (we could call them RFCs :-)

4. For a month or so we implement and test the accumulated error fixes, 
then release them. A six-month cycle (two releases a year) seems right 
to me.

Another option, if there are things which we thing need fixing outside 
this cycle, would be to release patches in the form of ODDs.