Hi Manuel,
> > 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?
>
> I am not sure if I understand. According to your plan, do the
> applications in Debian using ftgl will need to change anything at all
> to keep working? Because there's not much time for making changes
> before the freeze, I will be quite busy for a couple of weeks at least
> (so please excuse delays in replies if they don't arrive in a timely
> manner), and changes of this kind usually take months to be
> accomplished. It's not like we can commit changes to one or several
> git repos and rebuild the packages, it's quite more complex than that.
>
> IMO from the Debian side and for Buster there's no material time for
> changes to all packages that depend on fgtl, the only practical
> solutions are either to revert the change making some applications
> unuseable via extra patch from Debian; or have this transition and
> deprecation messages etc. in a way that existing packages don't need
> changes at all.
>
> Sorry, but I don't think that anything else works for Buster.
As I said, in the first step (2.4.0), they should not (assuming some
new warnings while recompiling are no problems).
Some changes will be necessary for 3.0.0, after Buster.
Cheers,
Frank
