> 1.1.9 is closed. Unless someone finds a show-stopper, it will be that > way forever. We don't expect there ever to be a 1.1.10. > > Any new 1.x style work will go into the experimental 1.3 tree, in an > attempt to move the 1.x and 2.x series back together, but without > orphaning the huge amount of 1.1.x code that is extant in the wild, and > without giving up 1.1.x's much vaunted stability. (from Roadmap) FLTK 1.3 is the current stable development branch based on FLTK 1.1.8. It will add internationalization, UTF-8 (Unicode), and printing support, Doxygen based documentation, and several new widgets including Fl_Native_File_Chooser, Fl_Table, and Fl_Tree_View.
somebody tell me, how it will get fltk1 nearer to fltk2 (except for 1.3 being really nearer to 2.0 than 1.1.10 in ariphmetical sense)? It just adds fltk2 features to fltk1. Codebases aren't getting any nearer. > > > 2) Adding new bugs to it through merging with fltk2 > > Both 1) and 2) add bugs, and add features. The key difference is that > > after 2) we'll have two times less projects to improve and maintain. > > Someone needs to take up 2.x and start fixing the bugs, particularly the > bugs that were fixed years ago in 1.1.x, and even more so the ones that > *were* fixed and have been re-broken. Then, maybe, we can look at moving > the 1.3 and 2.x trees together. > I haven't the time, nor the stength of will, to undertake that task, but > if somebody will, that would be a Good Thing. Sorry, but you miss my point. Once more, fixing bugs in fltk2 doesn't get codebases nearer. Merging then fixing is better than fixing then merging. We should merge libraries, not their bug trackers. I think everybody realizes that either merging or throwing-out one of the branches is a must-happen thing. The more we wait, the more code will be wasted and the more painful will it be. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
