> I know it is painful. I have been there. Nobody likes to fix bugs when > he could be implementing cool new features, especially if those bugs > don't interfere with my own projects. But lets face it: every little > new feature will cause at least four bug report and ten requests on > how to make that feature even better. But unless all known bugs are > fixed, a software will stay in beta (actually alpha, by definition). removed code is debugged code. I think much of the merged code would be from fltk1, and some fltk2 bugs would disappear. And we would have just less code. > My suggestion would have been to write a (close-to-perfect) > compatibility layer form FLTK1 to FLTK2, so that all F1 users can > switch to F2 without losing anything. I have a prototype that supports > derived classes and the full FL hierarchy with very few limitations, > so even the most sophisticated FLTK1 hackers could move on with no > changes to their source code. Unfortunatly, this will never ever fly > unless F2 is as stable as F1. So we wait for fltk2 to get stable, and then switch to it? By the time fltk1 will already incorporate all the fetures from fltk2 it needs. And we get: 1) same thing done twice 2) thrown-out fltk1 codebase. > So if F2 has no feature stop and only occasional bug fixing, what are > the other options? > > - Fix and emulate: the F2 team fixes F2, the F1 team creates a > better emulation layer Same thing but without feature freeze? Unreal :) > - F1 core, F2 API: make the FLTK1 API similar to FLTK2, but keep the > F1 core and adapt F2 changes? Basically it looks like just keeping improving fltk1 until we don't need fltk2 anymore(and provide fltk2-like interface). > - Megre by function: merge the libraries bottom up (basically your > idea?) and hope that the combined code remains stable? It won't always remain stable. But with united developer- and user-base that won't be a problem(imho). > - Merge by line: merge line by line in a Petri dish, creating the > essence of F1 and F2, calling it F3 > > - Weave: merge line by line while keeping the sum of code > functional don't see the point > - Kill one: abondon one of the two branches entirely nobody will agree with it(including me). But strategically it's the best choice. > - Kill both: or finally rename obne of the libraries and split > into two independent projects That's what is going on now(but pretending doing one project and using same mailing lists for more confusion) > > I have been weighing all this back and forth, trying to think of the > existing user bases first, but also how to attract new users > (definatly not with a confusing versioning), and how to attract (and > keep) core developers. I think the best thing can be done for attracting users is a stable version, and the best thing for distracting both users and devs is having two different implementations of the project developed separately.
_______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
