Matthias Melcher schrieb: > But that's exactly where the problem lies. When FLTK 2 was released, > only half of the users made the jump, and the other half (including > me) stuck with FLTK 1.
FLTK 2 was declared as "experimental" and I think, it's okay to end an experiment. But also there should be results, so what did we learn form FLTK 2? Maybe it shows, that branching into different directions can be a disadvantage (because of splitting users and developers) and users don't like to make heavy jumps? More? I think, there should be a straight line of development, that doesn't depart too much from stable versions. Add a feature, make it stable, go on with next feature... > THE STATUS ============ > > I converted the FLTK1 source code into FLTK3 namespace and added a > tiny bit of FLTK2 code. The result is a fully working virtually bug > free version of FLTK 3 (which at this point is FLTK 1 in new > clothes). To me this seems to be the right way. > I added a wrapper that makes FLTK 1 source code compile with the FLTK > 3 library. This is a true wrapper, not just some #define list of new > names. I have started a very minimal wrapper that makes FLTK 3 source > code compatible to FLTK 2 as well. To verify the effort, all FLTK 1 > tests compile and mostly run in this wrapper mode. There are still a > lot of bugs though! I don't like this. You added old stuff to new code, that's not light and fast, seems to make things complicated. Also this way goes on, to leave developers stuck to old code. > c: a big search-and-replace list will get > an FLTK 1 program 95% into FLTK 3 code What do you think of going a step further and using a conversion program? This also would make it necessary, to create a detailed description of differences (software documentation), but maybe even the program could be a tutorial, telling what it's going to do. 95% automatical by program and 5% of things, developer has to learn and think about, seems quite easy to me. The difference between FLTK 1 and 2 would be the difference of automatical transformation, but developers using experimental anyway are designated to learn some things more. ;o) > I think this is a really important point for FLTK. If we decide > wrong, and split user groups even more, that would be a disaster! If you want users to change, there should be a secure way to go from stable 1.x to stable 3.x. Anyway I think it's a good idea of having a 3.x version, because it's a clear version number telling of current ongoing software - the 1.stable und 2.experimental really was confusing. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
