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

[Syd Bauman]

> > ... Why not just continue development where the Guidelines are
> > right now? When there are a bunch of fixes, release a new version
> > (which I think should occur pretty frequently).
> the reason is that some fixes affect documents, others don't

I don't see how that answers my question. Yes, some fixes affect
documents, some don't. But why use a separate branch? 


> > If that new version changes the schemas, bump the "minor" number.
> > If it changes only typos in the chapters, change only the "bug
> > fix" number.
> the problem is that you can't fix things incrementally. 

Sorry, I don't understand this sentence. I'm not sure what an
incremental fix is, I guess.


> if I fix 25 typos, and you add 1 attribute, I can't make .0.1
> release without your added attribute.

Right. So it's not a .0.1 release, it's a .1.0 release. I don't think
anyone is suggesting that when you change the minor number, you can't
always fix typos. (Unless you are ... ?)


> I know that "release early, release often" is a mantra for
> software, but I am not sure its right for a pseudo-standard such as
> we are running.

Well then, we're opposites. :-) I hadn't heard that mantra (or at
least, didn't remember it), but think we should be pushing out those
releases that are backwards-compatible almost as fast as we can. If
we fix a typo, why should Terry Tagger and Emily Encoder have to wait
to see the corrected version? (I wouldn't say, BTW, that it's to
avoid making them download the package from Sourceforge: the *vast*
majority of TEI users read P5 via our website and access the schemas
via Roma or oXygen.)


> I'm all in favour of nightly builds, mind, to make sure people can
> track the bleeding edge. but thats why I want to fork, to let us
> have a bleeding edge separate from a stable bug-fix version.

Well, if I thought we were going to have a bleeding edge, I might
agree. But since we've constrained ourselves to backwards
compatibility, I don't think it's an issue. I may be proven wrong,
but my gut instinct is that a single development version is
sufficient. (If we start incorporating a significant change, like a
new module, that would leave the development version broken while it
is being instituted, we might make a branch for that issue at that
time, of course.)