> Fabien Costantini wrote: > > > That said, yes we should IMHO stop fancy modifications/improvements and > > focus exclusively on bug fixes asap. > > I agree in general (priority on fltk 1.3 release), but I still want > to get some ABI breaking things done before the release of 1.3. > > IMHO there are four main things that must be done before a release: > > (1) Get utf-8 support ready. There are still lots of things to do. > At least xft issues come to mind. More support for Eastern > languages may be postponed, though (IMHO). Ok, let's specifiy the _minimum_ features to realize before an RC can be released then. - First, the TODO.utf8 file is just a list a files (to be treated?), should be rename TODO_FILES.utf8 if it is still necessary? - Then a real TODO.utf8 should be updated with a full list of the features to fix/add - Then we should establish which are the priority tasks we want to fix in utf8 for 1.3. (i.e: I doubt it is a good idea to expect adding all langages supports in our next release : couldn't it be made progressively after that ?)
> (2) Check, which ABI issues should be solved before a FLTK 1.3 > release. I don't want to imagine how long it will take, until > we get the next chance to break the ABI, although I hope that > it will not take too long after the first release that we > start working on FLTK 1.4 with the next ABI (and maybe also > API?) changes. The point may be : what if instead of expecting to release beautiful-complete-abi-stable-proofed-the-one version, we just target smaller/ more manageable/frequent releases (like a new release every year approx.). Then I guess it won't be so terrible to wait for the next ABI change, wouldn't it ? > > (3) Fix bugs. YES, and the fact that the team is bigger today may help better than before. > > (4) Improve documentation. Yes, and probably focus on correctness and completeness more than on the aspect of the documentation, which still matters though. > > This is explicitly not an order of priority, but I think that > all parts are worth to be considered. > > I can help with (2)-(4), but I can't help much with (1). I can continue to fix UTF8 bugs, but I need a real TODO list to be established (see upper) and then priorities for 1.3. > So I'll focus on (2)-(4), but someone needs to do (1). > Unfortunately those who did the most work there are > currently not much available... Others may only do other > parts, however. We lived for years with a nice, yet simple html documentation, I think point 4 is ok for a release, even if it will always be perfectable. > > For me issue (2) seems _very_ important, because there are > lots of old STR's, maybe already from 2005/06 or even earlier, > that say "we can't do this for 1.1, because it would break > the ABI". Now we have 2009, and FLTK 1.4 won't come before > 2010 or 2011, right? Unfortunately, many of these STR's are > now classified as 1.4 feature requests, but we should have > an eye on those, too. Again, I'd highly suggest here that we (maybe you?) establish a TODO-CHANGES.abi asap so that we can have a clear view a determine limits to it. > > > We all like adding/improving features, and this is important that each and > > every one in the team can find an opportunity to do so ; afterall this is > > the least that a coredev deserves as a counterpart for so many everyday > > unfair maintanance tasks, but still what should be probably done now is > > focusing on a release. > > Yes, we need a release soon. But see above. The most important > point is to get utf-8 ready, then we can look what should be > done before the release, and what maybe later. > > > FLTK2 development history teached us a lesson of humility, IMHO: We should > > be happy of all that was already done in 1.3 ! > > Yes, that's true, we can be glad to have a growing developer > team :-) Yes, it's a real chance for us to have these quality people in the team, still we need to focus more on the _project management_ issue to lead us to success. IMHO What FLTK 1.3 really needs now is a solid manageable and realistic (short to mid term) direction ... And if Matt and Mike are a bit too busy right now, I think we (at least you and me and potentially everyone that want to feel responsible for this project in team) can do a good job meanwhile in that field ;-) > > Albrecht Fabien _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
