Re: development goals

[ludo@gnu.org (Ludovic Courtès)]

Hey!

"Neil Jerram" <neiljerram@googlemail.com> writes:

> For me, almost all of my time since becoming a maintainer has been
> absorbed by working on bug fixes, largely to do with slightly odd
> platforms (e.g. Mac) or architectures (e.g. ia64).  IMO it was
> worthwhile to focus on such bug reports soon after they were reported,
> because (i) the reporters are still around and interested enough to be
> able to provide more info and test fixes, (ii) I believe that running
> on more platforms will be good for the Guile community, and for Guile
> applications.

Same here.  But everyone is welcome to help fix bugs!  :-)

> Basically, my feeling is that Guile users have been badly burned by
> major release incompatibilities in the past, and I really don't want
> that to happen again.  Therefore my "straw man" plan is that
>
> - we stay on 1.8.x for a while

Which IMO means fixing portability bugs and the likes.

> - we treat "master" as a pot of goodies, which we aim incrementally to
> merge across and release as part of the 1.8.x series

The problem is that some of them might be subtly incompatible, mostly
because a lot of internals have been exposed and actually used.

I think it's good to have API and possibly ABI-compatibility within a
major release, so that "1.8.x" really means something, for any value of
`x'; requiring "x >= something" is acceptable IMO (we already have this,
e.g., with modules that got added in 1.8), but "a <= x <= b" isn't.

> - we don't do a big jump to 1.10.x, by just deciding to do so at some
> time (+ a bit of pretesting), because I don't feel confident that we
> can properly consider and document all of the 1.8 .. 1.10
> compatibility issues at once.

I agree that we should reduce the gap between any two major releases.

> But #1 : as I said above, I'm pretty sure Ludovic disagrees with this!

It's not all black & white.  ;-)

> I believe that programmers' natural tendency is to plan for infinite
> compatibility.

+1.

(That is especially true in Guile land where many projects are small and
developed only on people's spare time, whom you can't expect to dedicate
time switching APIs.)

> There you're right.  We can and should rip GH out now.  Actually that
> might make an excellent first example for documenting incompatibility.
>  (Anyone who really still needs it can take on the burden of
> maintaining the GH layer themselves.)

IMO, if it doesn't cost anything to keep it (beside `.so' size), let's
keep it.

Thanks,
Ludo'.