[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guile release planning
From: |
Ludovic Courtès |
Subject: |
Re: Guile release planning |
Date: |
Mon, 17 Nov 2008 00:55:50 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) |
Hello!
"Neil Jerram" <address@hidden> writes:
> 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
It partly fails for the second point. Examples: changing the
number/type of arguments of a function, changing the layout of a public
structure, changing the implementation of public macros, etc. It really
requires special care to check whether a change is breaking ABI
compatibility.
> 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 consider ABI compatibility as important, too, because people don't
want to recompile everything every time a minor release is out.
Like Andy said, we should guarantee it within a given series, e.g.,
1.8.x. After all, the version number is just a label giving users a
hint about the type of changes introduced in a version and level of
compatibility provided. It's common for free software libraries to
remain ABI-compatible within a major series (first and second digits
unchanged), to change to the second digit when ABI breaks, and possibly
the first digit when API breaks *or* important changes are introduced.
>> This is very convenient for binary distributions like
>> Debian, and for users in general.
>
> Are you sure about that?
Yes. Even for the few Guile C libraries I develop myself, it's boring
to recompile them when switching from 1.8 to 1.9 or one of the other
branches. For a distribution, it means burning a lot of CPU power.
>> 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.
Yes, but one con could be that it introduces changes that could be
visible to users that access Guile's undocumented module-fiddling API.
> 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.
>From a marketing viewpoint, the VM deserves a new version number. :-)
In practice, it also requires users to adapt their build system to take
advantage of it.
> 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.
I agree that a feature-by-feature approach would be more reasonable.
My impression, gathered since the time when Kevin was still with us, was
that the goal was zero-breakage within a stable series, such that
1.8.x+1 would always be more portable and reliable that 1.8.x. This
approach rules out things like the lazy duplicate symbol resolution, and
`libguile-i18n'. Surely we could find an "in-between".
> 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.
The BDW-GC change is ABI-incompatible, it introduces a new
dependency, augments the API and potentially introduces subtle changes
in behavior, so I would definitely change the version number for that.
Again, that version number is just a hint for users.
>> 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.)
I'm interested in the scm_c_read issue I raised on the list, and Linas
is interested in threading issues. The former seems more important to
me (eh eh ;-)) because it introduces a regression. Then, I don't think
we have to solve every single bug right now, it's already been too long
since 1.8.5.
Thanks,
Ludo'.
- Re: Guile release planning, (continued)
Re: Guile release planning, Neil Jerram, 2008/11/15
Re: Guile release planning, Ludovic Courtès, 2008/11/11
Re: Guile release planning, Sebastian Tennant, 2008/11/11
Re: Guile release planning, Han-Wen Nienhuys, 2008/11/11