From: ludo@gnu.org (Ludovic Courtès)
To: guile-user@gnu.org
Cc: guile-devel@gnu.org
Subject: Re: Guile release planning
Date: Mon, 17 Nov 2008 00:55:50 +0100 [thread overview]
Message-ID: <87ljvjcjjt.fsf@gnu.org> (raw)
In-Reply-To: 49dd78620811151603t67745c6fy7eb8b5134f883521@mail.gmail.com
Hello!
"Neil Jerram" <neiljerram@googlemail.com> 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'.
next prev parent reply other threads:[~2008-11-16 23:55 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-11 1:23 Guile release planning Neil Jerram
2008-11-11 1:59 ` Mike Gran
2008-11-15 23:03 ` Neil Jerram
2008-11-15 23:19 ` Mike Gran
2008-11-11 3:44 ` Linas Vepstas
2008-11-11 17:10 ` Greg Troxel
2008-11-11 20:00 ` Andy Wingo
2008-11-11 21:05 ` Linas Vepstas
2008-11-11 22:06 ` Andy Wingo
2008-11-11 20:18 ` Ludovic Courtès
2008-11-15 23:16 ` Neil Jerram
2008-11-16 23:33 ` Ludovic Courtès
2008-11-17 20:49 ` Andy Wingo
2008-11-18 10:22 ` Ludovic Courtès
2008-12-08 22:05 ` Neil Jerram
2008-12-09 17:01 ` Ludovic Courtès
2008-11-11 15:32 ` Sebastian Tennant
2008-11-11 20:30 ` Ludovic Courtès
2008-11-16 0:03 ` Neil Jerram
2008-11-16 5:11 ` Linas Vepstas
2008-11-16 12:46 ` Greg Troxel
2008-11-16 23:55 ` Ludovic Courtès [this message]
2008-11-12 4:41 ` Han-Wen Nienhuys
2008-11-12 19:11 ` Andy Wingo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ljvjcjjt.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-devel@gnu.org \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).