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

[Dan O'Donnell]

Of course one should read all the way through a thread before
responding:

I like all of this, except for 3: is there a reason not to keep the sf a
"use at own risk bleeding edge" repository? I.e. make the fixes and park
them during the inter-public-release period?

-dan

On Wed, 2007-07-11 at 10:34 +0000, Lou Burnard wrote:
> 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.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- 
Daniel Paul O'Donnell, PhD
Chair, Text Encoding Initiative <http://www.tei-c.org/>
Director, Digital Medievalist Project <http://www.digitalmedievalist.org/>
Associate Professor and Chair of English
University of Lethbridge
Lethbridge AB T1K 3M4
Vox: +1 403 329 2378
Fax: +1 403 382-7191
Homepage: http://people.uleth.ca/~daniel.odonnell/