[tei-council] next release

[Syd Bauman]

SR> because, as I keep saying, you cannot then separate out a
SR> definitely harmless release from a potentially impactful one

But *especially* if releases are only occurring every 6 months, this
does not seem like it is very important. And who's the "you"? If we
were to use the version number in such a way, the user could tell
from that. So I am pretty unconvinced.


JC> Any time I've tested merging things from one branch to another in
JC> SVN I've ended up with problems and complications.

I agree -- I've only actually tried a branch merge once on P5 that
I'm aware of (the re-org branch), and I was unsuccessful at merging
it back, and had to do a lot of stressful copying around by hand
instead.

If I thought it was going to buy us anything, I'd be in favor. If
there is some significant project that comes up, I'm still in favor.
But for just routine fixes, I don't see the point.


JC> Well, I'm generally in favour of doing what is best for us,
JC> rather than what is easiest -- so if you think branching is best
JC> then I'd like more explanation I guess.

Hear, hear! Me too.


JC> [on Birnbaum doctrine] But we should note that the proposal isn't
JC> that we won't break backwards compatibility, but just where more
JC> substantial and comprehensive breaking ...

But this is not the constraint we are currently living under. It was
clearly stated at the Members' Meeting that we were living to a
higher standard than the Birnbaum doctrine. It was stated at least
twice, once by Chair of Council, that we were not going to make any
changes to P5 which would make existing P5 1.0 instances invalid.
Now, I'm pretty happy with the Birnbaum doctrine. But not breaking
instances -- that's a tall order, throwing even correction of
corrigible errors into doubt.

Of course, in some cases, we can still make repairs. E.g., changing
the (broken, IMHO) version= of <TEI> could probably be accomplished
without technically making any existing instances invalid. (This is
because version= is not defined as data.numeric, but rather directly
defined as xsd:decimal -- not using our own system has bought us a
little bit of breathing room! :-)

Of course, it might still be meaner than we want to be to users --
changing the default value from "5.0" does not break any existing
*instances*, but might well break *processes* that rely on that
value. 


LB> [on deprecation]

I'm with Lou. If we are going to add a formal indication of
deprecation, it has to go on the <elementSpec>, <classSpec>,
<macroSpec>, <attDef>, or <valItem> in question. But more
importantly, it isn't really necessary. At least for now, saying so
(in the tagdoc, not just the prose) is sufficient.