> - we immediatly stop any development on 1.3 and 2.x (that's the easy > part ;-) > - we set up a new branch in the SVN called FLTK 3 (aaaaaaaaah!) > - then copy *both* code bases into this branch, renaming directories > so they can coexist (src1, src2, test1, test2, ...) > > Now we start another library inside all this: FLTK3 > - we need to set up a directory structure to support a modular FLTK3 > - we need to merge the autotools environment and IDE project files of > F1 and F2, so that *both* libraries *plus* F3 will be built, and both > F1 and F2 link against F3 (which is still empty at this point) that would be a bit confusing - fltk1 and fltk2 depending on fltk3 :) I like the idea of having them all bundled together, but I'm for the abstraction layers being a separate library. Even if we somehow merge widget systems, that would force independance of gui things and abstraction layers. > - we need to set up a system for regression testing yep, that would be nice. everything but windowing can be tested automatically. by the way, if we go for it, that would be a good time for changes in infrastructure. for ex.: 1. Switch to a distributed revision control(git, mercurial). I myself switched from SVN to Mercurial some time ago very easily. It has its advantages(most evident - local commits). By the way it's possible to use them simultaneosly and keep in sync. 2. Make a web interface to revision control system. Like: http://hg.sharesource.org/sharesource/ 3. Improve bug trackers - add keywords, for ex. to group bugs based on the subsystem involved Like: http://www.selenic.com/mercurial/bts/issue?%40search_text=&title=&%40columns=title&%40sort=title&topic=&%40group=topic&id=&%40columns=id&creation=&activity=&%40columns=activity&priority=1&status=&%40columns=status&%40pagesize=50&%40startwith=0&%40action=search > > And now comes the big trick: > - we create the F3 OS support and core by *moving* and merging F1 and > F2 core files (see the list above). The trick is not to *copy* those > files, but to *move* them. That means that F1 and F2 will *loose* > functionality in its own core, but will regain an improved > functionality by linking back to F3. > > This trick has a many advantages: > 1: no coding is done twice (we need to keep a minimal glue layer > between F1 and F3, and F2 and F3 though) I think fltk2 needs no compatibility layer. the moved interface will be itself usable. Those who use fltk2 don't expect the API to be immutable, I guess ;) > 2: all developers work on the same project > 3: all developers can review their peer's code > 4: all *users* can continue to use their favourite API with a stable > understructure (and keep testing what we write) > 5: we *finally* present a unified image to the outside world again > > We will reach a point when the core is ported and individual widgets > will have to move. If everything works as I expect, we will then be > left with the compatibility layer that I mentioned in an earlier mail. > Nice. > > I am all for it. Let's do it right. Nice to hear that :)
_______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
