> Ah no. fltk1 and 2 don't depend on fltk3. The f1 and f2 compatibility > layer will. ven though we are starting out with the full library, we > will end up with very little code in the f1 and f2 directories, > sometimes just with a header file. Maybe do it this way: 1. Separate core code to logically separate library fltk-base 2. When it's ready, leave it. the main milestone, the following is optional. Then we sit and think about what to do with widgets code. 3. We start to merge the widgets system. *This* will be fltk3. 4. At the end point we have abstraction layers in fltk-base and everything else with compatibility code in fltk3. The point is - to ensure the separation. fltk3 code will be completely platform-independent. fltk-base will be useful itself as a cross-platform library. > >> - 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). > > I have used GIT and SVN. SVN was always sufficient for me and has a > great front end. Please explain (or give me a reference where I can > read this up) how GIT will improve revision control. The most important - having full repository on a local machine. 1) local commits 2) offline operations. I myself have very crappy connection, it can be down for days. 3) easy changing revisions. It enables you, for example, to binary-search the repository for a regression - Mercurial's "hg bisect". 4) I can have many cloned copies of the repository, work on different features simultaneously and pushing/pulling changes between them easily. That's for me easier than SVN branching (actually, I switched to mercurial before I made it work) Short comparison of mercurial and svn from the mercurial manual: http://hgbook.red-bean.com/hgbookch1.html#x5-180001.6 > > 2. Make a web interface to revision control system. Like: > > http://hg.sharesource.org/sharesource/ > > I never needed that because TortoiseSVN provides that much faster, but > again, I am happy to learn why this is useful. Me too. I don't know why I wrote that. Well, it looks nice :) By the way there is TortoiseHG. Haven't used it, though. Well, anyways, I think it's not the best time to switch. I might try to setup a mirror somewhere. > > 3. Improve bug trackers - add keywords, for ex. to group bugs based > > on the subsystem involved > > OK, that should not be too hard. You can do much more complex text > searches than meets the eye already though. > > I will put this in the hand of those who know more about regression > testing and version control than I do. When I studied Computer > Science, version control meant "using another audio tape to store your > source code and keeping the old one away from the little sister" ;-) .
_______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
