> > 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