Re: Re-addition of deprecated stuff to 1.7.

[Marius Vollmer]

Bruce Korb <address@hidden> writes:

> Marius Vollmer wrote:
> 
> > I'd say it is a trade-off between how much pain you are willing to
> > inflict upon your clients and how much pain you are willing to suffer
> > yourself.
> > 
> > I think (and hope) it is entirely tolerable to require you clients to
> > install Guile 1.6 when they want to compile your code.
> 
> As the author of a piece of code that is relatively obscure,
> it is tough enough to get it test-driven, let alone test-driven
> after they have had to upgrade something else.  Current distributions
> are still using 1.4 (leastwise the latest Red Hat 7.x and SuSE 8.1
> use it).  These releases are not even a year old yet.  It *will*
> be a couple of years before it is reasonable to expect all potential
> clients to have 1.6.

Yes, maybe.  What about talking the distros into providing Guile 1.6
sooner?  That would make more sense, in my view.  We could provide
RPMs for Red Hat, Suse, and DEBs for Debian stable.  That will make it
easier to retrofit ones system with Guile 1.6.

> I sent some macros, tho I coded around the need to use it myself.
> 
> > These configure snippets might be collected in a central place, maybe,
> > when people are willing to maintain such a thing.
> 
> That's what I was suggesting...

Ok.  So how shall we proceed?  I'm don't want to make it a
release-critical goal of Guile 1.8 to come with such a set of snippets
unless there is more demand from 'the community'.  However, the
snippets can be collected in the Guile CVS repo, when people want to
do that.  We will have to apply all the usual FSF legal rules to them,
tho: copyright must be assigned, etc.

> [...]  I do want to say that the compatibility glue is important.  I
> am now developing against 1.6.  However, as much as you would like
> to see 1.4 retired, the bulk of the distributions at this time have
> 1.4.  I need to be able to jigger what I use so it can adapt to
> whatever is locally installed.

So you are effectively targeting 1.4 and 1.6, not just 1.6 alone.  I'm
not sure what kind of compatability glue you are talking about: do you
want to have a layer that makes 1.4 identical to 1.6?  Or do you want
a layer that fixes bugs (such as the gh_scm2newstring size_t bug) so
that code that worked with 1.4 continues to work with 1.6?

Neither of these two types of compatability glue makes much sense to
me: for the first, it is easier to use the genuine Guile 1.6 as the
'layer'.  Just package it with your code when you don't want your
clients to download and install it themselves.  For the second type,
it is easier to just stick with Guile 1.4, which should be available
already on your clients system, as you say.

>  By the time the bulk of installations are running 1.6, you'll be
> shipping 1.8 and using the same arguments.

Yes.  And I sill think they are sensible arguments.

> [...]  OTOH, when you retire ``scm_port'' you could also add:
> 
>   #if (THE_LAST_GUILE_VERSION_I_KNEW_ABOUT < GUILE_VERSION_1_6)
>   #  define  scm_port scm_t_port
>   #endif
> 
> and delete that code only after 1.6 has been in the major distros
> for a couple of years.

Yes, we are doing this now (kind of) and are being more careful than
we have been with 1.6.  See the "Handling of Deprecated Features"
section in the README.

Incidentally, "scm_port" is available with Guile 1.6, but I see that
you want to have "scm_t_port" with 1.4.  That's a strange thing to do,
in my view: you can't get the 'goodness' of 1.6 from 1.4.  You might
create the illusion in simple cases like scm_port, but this wont work
in general.  The result is code that is written is then a, in your own
words:

> The Guile version I understand is a mix of 1.4 and 1.6 'cuz I'm
> transitioning.

Coding for such a mixed API is not on the path of least pain, I'd say.

> > It is of course good practice to minimize the needed changes,
> 
> I'm sure you do your best.  One's best cannot ever be perfect.

But we are getting better!  :-)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405