Hi,
coming back to my own mail, after thinking about it some more:
: > And I think that the default would have to be the old behaviour, yes,
: > because after many years behaving in that way the applications must
: > have learned to adapt or cope, and no one knows that they have to use
: > a different flag or invoke the method with an extra parameter.
:
: For some value of "the applications". You're talking about Debian
: only again, of course, but there are other applications that have
: come to expect the new behaviour (obviously at least mine and the
: patch author's ones, possibly more -- there's a number of forks of
: FTGL on github, probably by people who use(d) it).
:
: > I realise that maybe this is not what you like because applications
: > will ever remain buggy, but reallistically,
:
: The same applies vice-versa for applications that rely on the new
: behaviour if we make the old one the default.
:
: The problem is we have different semantics already (and for almost
: 10 years apparently).
:
: Perhaps the only sane way out is to add *two* new versions of each
: rendering function, one with each behaviour, and deprecate the old
: ones entirely. This will require changes in all applications (if
: only to select the correct one of the two which should be easy if
: ones knows which branch of the library they used before), but at
: least it will be clear at compile time.
That seems to me the best solution indeed. So I can offer this:
- I add these two new versions for all functions involved (quite a
few); we'd just need to agree about naming ("old" and "new" won't
do, since in this complicated situation it's not even clear which
one is old and which one is new; different users will view it
differently, just like in special relativity ;), also "old" and
"new" in function names always sounds silly; so perhaps something
like "RenderBasic" and "RenderDefault" or so ...).
- I deprecate the "Render" functions, adding a special README to
explain things.
- I change my sources to use "RenderBasic" (or whatever it'll be
called) and test them. Other users of this fork will have to do
the same (hopefully after seeing the deprecation warnings and
reading that README).
- I release 2.4.0 with those changes.
- You put 2.4.0 in Debian. Applications using it will get the
deprecation warnings, but should otherwise work.
- A bit later, I remove the deprecated functions and release 3.0.0.
- After the release of Buster, you put 3.0.0 in Debian with the
required transitions.
- Applications using it will break, but fixing them will only
require changing "Render" to "RenderDefault" in some places
(which are found by compiler errors). This can also be done before
you upload 3.0.0 (as "RenderDefault" will be available in 2.4.0
already), so the transition can be smoohter.
Does this sound like a viable plan?
Cheers,
Frank
