Re: Guile release planning

[Ludovic Courtès]

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'.