[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: gschem with cairo rendering



> The following is an opinion and nothing more - Designing the
> architecture of a program and then writing code for it like it's 1999 in
> the year 2008 makes no sense whatsoever to me.

I have no problem with that statement.

My point is rather:  Backwards compatability for some fixed period of
time is a good thing, and will help users who don't want to hassle
with too many dependencies which haven't become mainstream yet.

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".  I can look into what this
means in terms of GTK, Cairo, gettext, etc. versions if desired.

Others are welcome to suggest a longer or shorter time period; I just
put 4 years out there as a bogey for folks to pee on.

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.  And -- I agree with Ales -- they should strive to provide
the same features using the old libraries as they write with the new
ones.  Within the limits of reason and possibility, of course!

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, then it leads to tears for users who aren't well versed in
getting and installing obscure Linux packages.  It's even worse if
libfoo only provides eye candy or some other inessential feature, but
ends up creating a headache when a user is forced to install it simply
to run an app.  My aim is to strike a balance between the needs of
developers (great new libs to build opon) and users (stable code
without lots of dependencies creating a dependency hell situation).

Cheers,

Stuart


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user