Chris Shoemaker <[EMAIL PROTECTED]> writes:
> I had been ignoring that warning for quite a long time now, but after
> seeing the backtrace in the logs, it's quite obvious what's causing
> them. gnc:config-file-format-version doesn't exist anymore. That
> raises an interesting point...
Hmm, I wonder when that went away?
> These days, I'm especially mindful of forward and backward
> compatibility concerns. I think we need to think carefully about what
> expectations our users might have about the compatibility of their
> config files. By allowing the user to supply a guile file to be
> loaded at startup, we're giving them enormous flexibility to change
> the behavior of gnucash. But, we're also exposing an _enormous_
> public interface -- essentially every guile function and gwrapped
> function or datatype -- an interface that I don't think is so ready to
> be cast in concrete.
I think it's okay -- other applications that expose such a large
interface (e.g. emacs) change that interface over time. In our case,
the g-wrap functions HAVE been relatively stable. Also, gnucash never
makes any guarantees about the stability of APIs across "major"
releases (where "major" really means "minor" in the sense that 1.6 ->
1.8 was considered a "major" release).
> I think we have several options. The simplest is to simple warn users
> that custom guile scripts they write could be broken by even minor
> releases. Another option is to be more rigid about what data we load
>>From guile config files. We don't _have_ to execute the user's
> program -- we could just pull out certain config values. I'm sure
> there are more options.
I think your first option is fine.. We already break configuration
across releases. For example, changing the name of a report (which
happened with a LOT of reports in SVN vs. 1.8) breaks existing
configurations... This happened from 1.6 -> 1.8 too. So, I think
there's precedent for "ignoring" certainly configuration state across
an update.
User-defined scripts IMHO fall under that umbrella.
> What I want to avoid is the sense that we can't change any g-wrapped
> function or guile function just because we're potentially executing
> user scripts that may use any of those. It's something to think
> about.
*shrugs* I don't think there's ever been any sense that those APIs are
set in stone. I think we're safe. If it makes you feel better we can
better document that there are no guarantees on the stability of APIs.
> -chris
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
