Re: [PATCH] Thread Plug-in Support #2

[Rob Browning]

Rob Browning <address@hidden> writes:

> This might be good enough, but if we're going to follow this route,
> then it seems like we probably need to make a policy that all guile
> add-on packages should always use API version numbers in their names
> and all packages that depend on those packages should use the
> versioned names in their use-modules statements.  I.e if your add-on
> module depends on gtk, you should say
> 
>   (use-modules (gtk2 gtk))

One other related problem that this number-in-name approach doesn't
help (or least doesn't solve intuitively), but that that the more
explicit scheme module :version :revision :age approach would resolve
is a situation like this:

  (1) guile 1.6.0 is released.

  (2) a module for gtk, providing bindings for gtk 2 is released using
      by-hand wrappers as say (gtk2 gtk)

  (3) other modules are released that depend on this module.

  (4) a new version of the gtk wrappers is released where the upstream
      has switched to using another approach (say g-wrap) for
      generating wrappers, but the gtk version being wrapped *hasn't*
      changed.

This new guile module might not be able to use the same name as the
previous one, say (gtk2 gtk) since its implementation and maybe some
of it's API are not compatible with the old (gtk2 gtk).

However, if each module had been released as

  (define-module (gtk gtk) :version 6 :revision 2 :age 0)

and

  (define-module (gtk gtk) :version 7 :revision 1 :age 0)

then there's enough information to detect and avoid the compatibility
problem without having to put confusing non-gtk related version info
into the module name.  i.e. this would work, but would be confusing
IMO:

  (define-module (gtk2 gtk))
  (define-module (gtk3 gtk))

since the numbers here would *not* be indicating gtk versions, but
scheme gtk module versions.

And again, I'm not saying we should/have-to do anything like what I'm
suggesting.  I just want to make sure we've considered the
implications of anything "simple" we choose, and that we're not just
sticking our head in the sand wrt to future problems we might be
forced to deal with.

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930