> > My suggestion of 2018-11-25 still stands. But if you want me to do
> > my part of it, please do your review quickly and tell me soon
> > (or, if it's indeed necessary for the soft freeze, immediately) to
> > avoid running out of time.
>
> Your plan sounds OK. Changing packages after the release, with time,
> should be OK. I can submit automatic bug reports for the affected
> packages.
OK.
> Maybe it would even be possible to have the applications set a global
> variable, e.g.:
>
> enum class Render { Default = 1, Basic };
> FTGL->setRender(Render renderType);
>
> and then the Render() function(s) would dispatch to either
> RenderDefault() or RenderBasic() versions as appropriate?
I generally don't much like global flags, but in this particular
case, it might be the least painful approach.
It wouldn't be foolproof. If two pieces of code, e.g. libraries,
that are used in the same program, use Render() with different
settings of this flag, one of them would do the wrong thing. (And
manually changing this flag every time code from the other library
may be used would be a maintenance nightmare.)
So maybe the following is even easier to implement, while also not
foolproof:
- No RenderDefault() and RenderBasic(), just Render() as is.
- A flag similar to your proposal (though I wouldn't actually call
it "Render..."; if we aren't renaming the Render functions, we can
use a more specific name), such as LegacyOpenGLState, and it can
be a bool actually.
- However, ftgl will only allow setting this flag to one value ever
(but any number of times, so libraries that expect the same
setting can work together). I.e., if it's set to false, further
calls setting it to false will succeed, but a call setting it to
true will abort, indicating a mix of incompatible code pieces; and
vice versa.
If it's never set, if will default to true (legacy behaviour);
I'll have to accept that.
- In my code I'll set it to false; likewise for others relying on
this behaviour. (My code actually contains libraries using ftgl,
so I'll make sure to set it from within the libraries, rather than
the programs using them.)
- Programs relying on the "old" behaviour need no change
immediately, but should soon (so for Debian, after the release of
Buster), add a "true" call. This would be a single line change
near the start, so easy to do even if it affects a number of
packages.
- Both kinds of program will need to require ftgl>=2.4.0 because of
the new call.
- Sometime in the future, I hope I can require setting this flag,
first with a warning, later with an error if it's not set before
the first rendering. Provided you've added the call to all
packages by then, nothing will break.
Cheers,
Frank
