On 01/09/12 03:19, Albrecht Schlosser wrote:
> The reason why I suggested a version number and not a simple on/off
> switch is that someone could enable all 1.3.2 ABI features, and then
> upgrade the sources to 1.3.3 or later, but still keep ABI compatibility
> with the previous headers and shared libs, even if 1.3.3 or later
> added other ABI breaking features.
Mmm, I see.
I can kinda see an app programmer might /want/ that,
but as a dev I'm not sure we should support it, because then the
version possibilities span into a wider tree with each subsequent
patch release.
As a dev, I'd be concerned if, let's say I add ABI feature "XXX"
in 1.3.2, and then had to modify that code in 1.3.3 to track
or work with a new ABI 1.3.3 feature called "YYY".
Now I have to support my 1.3.2 XXX feature both with and without
the 1.3.3 YYY feature, which means combing apart the code
to support both.
Since we've had patch levels get to 11 and more, I kinda shudder
to think how complex the ABI feature tree could get at that level.
As a dev, I'd rather not try to support that at all; if the end user
wants ABI features enabled and upgrades the lib, they shouldn't expect
to use older shared libs period.
This way devs of an ABI feature only have to debug with ABI features
on or off.
And also, won't have to walk on egg shells when touching ABI feature
code in subsequent patch releases.
It would also ensure new ABI features get vetted as patches come out.
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
