Michael Sweet wrote: > > 1.4 could then add printing and any other useful stuff that is ready > for consumption. > Yes, the useful poll would be to determine how much people care about ABI. I would guess that most people care rather about source compatibility and often distribute fltk with their applications. I myself link the stuff mostly statically (thanks to small fltk footprint and benevolent fltk license) to avoid dll hell so ABI compatibility is not an issue for me. If the binary compatibility is not so important for most of the users (you can not please everybody), adding larger features (which would break ABI) one-at-a-time and release often is is a good approach (also fixes can go to that new versions in the mean time). This would simplify the synchronisation so that the feature additions would not need to wait too long. And once the release is relatively feature complete - like UTF-8 + printing (+styles) - it could be declared "LTS" (shamelessly borowed from Ubuntu terminology :-) with ABI-compatible bugfixes and inflation only in patch version numbers - ie for adoption by distros.
Releasing often is a good thing - even if not all bugs are fixed. The discovered bugs are often present in previous versions too (which were released as with no high priority bugs) so that it does not necessarily mean that the version is less stable. To somewhat distinguish when the 0 high priority bugs are reached, the patch versions could be ie differentiated by odd/even numbers so that releasing sequence could go like: 1.x.0, 1.x.2, 1.x.3 (indicates 0 hp STR), 1.x.5 (indicates 0 hp STR), 1.x.6, 1.x.8, ... Roman _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
