unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
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'.





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