Re: Guile release planning

[Neil Jerram]

2008/11/11 Ludovic Courtès <address@hidden>:
>
> Your note doesn't take binary compatibility into account, and I think
> it's an important thing, too.  I think the ideal is to maintain binary
> compatibility within a major series, as we've done (or tried to do) in
> the 1.8.x series.

(And Andy wrote "I think it needs to be guaranteed.")

But this isn't obvious to me.  _If_ the libtool versioning system
works in practice, in the senses of

- permitting linking when it ought to be permitted

- failing linking when it ought to fail

- providing a clear error message in the failure cases, so that the
user knows what to do next

then it seems to me that a reasonable division of labour is for us
(upstream) to take care of API compatibility, and ensuring that the
libtool numbers are a correct description of ABI state, and for
distributions/users to take care of any consequences of mismatched
libtool numbers.

I think the latter "consequences" are just having to recompile
something against the new libguile version.  For a user who has
already decided to use the source code version of an application, that
should be trivial; for distributions, that's just what they do all the
time, isn't it?

Are there other consequences that I'm missing?

Sure, we could also take on ABI compatibility ourselves, but I think
that overconstrains our development, and/or makes it harder.

> This is very convenient for binary distributions like
> Debian, and for users in general.

Are you sure about that?  I would expect Debian already to have
completely automatic ways of coping with this kind of thing (i.e.
libtool numbers changing).  And I've described what I think the impact
on users is above; seems quite small to me.

> I think enhancements like the lazy symbol binding in modules
> could have been in theory added in 1.8.x since it breaks neither the API
> nor the ABI.

Agreed; and I think they still can be added in 1.8.x.

> Things like `libguile-i18n' could have been added too, but
> the issue when adding C code is portability: it may be that this module
> would have caused build issues on some platforms.  Now, with more
> frequent releases, it would be reasonable to hope that such regressions
> would quickly be fixed.

Agreed, I think we can handle this.

> Another thing is actual big jumps.  I think the addition of the VM is a
> big jump.

Yes, but it's an addition.  As far as I understand, it's completely
back-compatible, so I would be perfectly happy to feed this in to
1.8.x at some point.

Of course, we should take care that we are 99% happy with the new APIs
before releasing them, as it wouldn't be good to make lots of changes
later.  But that's no different from the first public release of
anything - in my view, it should work much better for us to come to
this determination feature-by-feature, than to say arbitrarily at some
point "everything in master" is now ready.

>  A GC change, or a rewrite of the string/char code with
> Unicode support would be a big jump, too.  Such big jumps surely need a
> new major release.

Not necessarily, in my view.  We have an extensive test suite, and I
think we can have some confidence in that.  After sufficient testing,
I would see no problem with your proposed BDW-GC changes going into a
1.8.x release.

Same for Unicode support - if the API stayed compatible.  If the API
could not be compatible, then I would agree that we might need a new
major release.

> BTW, we need to consider releasing 1.8.6 one of these days!  ;-)

Yes.  Do we have any particular more things to get into this?  (I
don't think I have anything.)

     Neil