Paolo wrote: > It does not, but splitting development in 3 branches would > allow easier release of each.
I see where you are coming from, but to me it becomes a bit of a "divided we fall" situation. As the GUIs have developed in tandem we've added little library and module functions along the way when some variable needed to be exposed or some function deineractivated (if that word makes sense). Development is not completely independent, especially if you consder the mixed components like wxVdigit and wxNviz. > For instance there is a critical bug in one of the GUIs, > but CLI is not affected, then libgrass can be released, Currently we have pretty much a max of 2 people working on the GUI at any one time. With the current release stalled primarily due to GUI on Windows issues it forces me to at least look at that code, even though I usually don't use either the GUIs or Windows myself. If it were separate that incentive wouldn't be there and the gui devels might get lonely and discouraged. > and other apps (including QGIS) can rely on a stable release. ? AFAIK they can and do rely on the releasebranch_6_4, which should be stable enough not to be sensitive to this issue. > The basic idea is that CLI and GUI have different speed of > development and diffwerent stability issues and requirement, > so when it is possible to allow different speed of release, > this *seems* to me a good option. I worry that with a multi-tier system the lesser developed components would be further neglected by the other devels. The GUI is not-scriptable so the UI parts of it can change quite a bit within a stable release cycle without being limited by the preserve-backwards compatibility rule. regards, Hamish _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
