On Mon, 05 May 2008 17:57:32 -0400, Stuart Brorson wrote: > I suggest a target of ${DATE} - 4 years, which is pretty conservative, > but reflects the update cycle of many desktop users. That is, whatever > was prevelant on the usual distros 4 years ago should be our "lowest > common denominator".
You suggest to target desktop users that use a distro, but choose to not update their system for the entire life time of the box. I don't know any non-windows user with such an attitude. Ease of update is one of the main benefits of sticking to a distro. For the sake of the argument, lets assume, there is a relevant population of this kind among the geda users. You imply, that these very users, who choose to live with dated versions of applications on their desktop wish to run the bleeding edge version of geda. Why would they? Wouldn't it be much more likely they simply continue to use the version of geda found in their dated distro? Unless the file format is changed such that old versions of geda can't deal with files produced by the bleeding edge build, I see no reason why a user who chooses to use a dated system should not use a dated geda. That said, geda (and pcb) should make sure, their bleeding edge version only depends on libs currently readily available for the targeted OSes. This includes of course, various unix flavors already mentioned in this thread. It should also include at least one of the possible ways to do a MS-Win version. > Of course, if developers want to include newer libraries into the code, > then they can -- but must make sure their stuff is off by default. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ For what reason? New stuff should be on by default as it likely represents an improvement to the majority of users. If it doesn't, it should not have been pushed in the fist place. Features not activated by default at compile time are next to non-existent. If there is a relevant portion of target systems where some libs are not readily available, then the configure should set a flag and issue a note in the summary. > The point is that it's too easy for a developer to make libfoo a > dependency for a project in order to get some shiny, whizzy feature. But > if libfoo is experimental and not widely distributed in stock distros, I have no problem with this general statement. However, it does not apply to the case this thread is about. Both, cairo and freetype are far from experimental, but widely adapted. This is 2008, not 2004 when cairo was proposed to enter the infrastructure of gnome. Both libs are definitely not linux only. To the contrary, cairo and freetype are both successful efforts to provide features independent of OS. ---<(kaimartin)>--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key: http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmk&op=get _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user