Hi Frank,
Em dom, 25 de nov de 2018 às 18:29, Frank Heckenbach
<f.heckenb...@fh-soft.de> escreveu:
>
> : 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?
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.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
