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

[Sebastian Rahtz]

Lou Burnard wrote:
>
> 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)
>   
not that this is what Subversion is for. it is good at it.
> 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
>   
that's argument in favour of branching....
> 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.
>   
fine
> 2. Obviously erroneous typos and inconsistencies which dont affect 
> schemas get fixed immediately in SF.
>   
fine
> 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 :-)
>   
making Trac public, I assume?
> 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.
>   
ok
> Another option, if there are things which we thing need fixing outside 
> this cycle, would be to release patches in the form of ODDs.
>
>   
we don't have the technology for this, attractive
as it sounds in theory.

-- 
Sebastian Rahtz      
Information Manager, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431