On 09.01.2012 21:43, Greg Ercolano wrote: > 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.
Yes, agreed in parts, it would become more complicated to manage by the dev's. But it shouldn't be a tree - it's going to be one line of additional changes for each release, so what you would have to do is only to check whether all ABI feature macro settings from 10301 to 10305 (e.g., for release 1.3.5) would be compatible, and this would only be necessary, if we changed ABI features of one release again in a later release. Taken into account that the nature of the ABI features should be very limited (e.g. to one widget only), this shouldn't be hard. If ABI features didn't depend on each other, we could even only use the latest ABI feature macro value to enable all features together for testing. > 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. This shouldn't happen, if we (the devs) didn't "abuse" this feature. It should really be limited to local changes, and should be used as little as possible. > 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. Not a tree, only a chain of maybe independent features (see above). > 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. We should document this as our strong recommendation, but if a software developer likes to do it against our recommendations, why shouldn't s/he do it? > 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. With a little discipline, there is only off (e.g. 10300, the default), or on (the highest applicable value, e.g. 10305 for 1.3.5), and this would enable all ABI features. Let's document that all intermediate values are possible, but unsupported and not necessarily working... Albrecht _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
