On 22.09.2009, at 18:39, Greg Ercolano wrote: > > I don't know how to weigh in on changing 1.1.. > I guess it depends on how clearly we can warn people about > the change; > > -1 if no warning is used > > +1 if the warning is clear (ie. configure warns with a big banner > when the old links are detected, and configure has links > turned off) > > The big warning should probably include a URL to an article on > the FLTK site > or a README file in the distro describing: > > a) the details of why the links were disabled > b) short history of why they were added, then later removed, > c) what problem they create > d) what app builders should watch out for if they're on > e) what app builders should watch out for if they're off > (ie. crashing programs if links remain, or apps that won't > compile due to casing typos causing #include errors) > f) recommend how to fix the problem by telling people how to remove > the old links.
I see 1.1.10 as a last resort for those who can not or will not go to 1.3/3.0, or whatever will come next. They can fall back to the latest and greatest 1.1 version. Changing the way the include files work will ruin the fallback. Then they have to either go to 1.1.9 or start changing code (that may not even be theirs). IMO, we should not change the default links setting in 1.1, but absolutely do it in 1.3 including a warning. Actually, for 1.3.0, we could remove the symbolic links and instead create files that include a #warning statment, then later an #error statement, kind of slowly deprecating the "feature". Matthias _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
