2008/11/11 Ludovic Courtès <[EMAIL PROTECTED]>:
>
> 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
