Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Sven Luther <sven.luther@wanadoo.fr>
To: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
Cc: sven.luther@wanadoo.fr, caml-list@inria.fr,
	debian-ocaml-maint@lists.debian.org
Subject: Re: [Caml-list] binary compatibility of 3.08.3
Date: Sun, 16 Jan 2005 19:23:03 +0100	[thread overview]
Message-ID: <20050116182303.GA32427@pegasos> (raw)
In-Reply-To: <20050116.082637.115932729.garrigue@math.nagoya-u.ac.jp>

On Sun, Jan 16, 2005 at 08:26:37AM -0800, Jacques Garrigue wrote:
> From: Sven Luther <sven.luther@wanadoo.fr>
> 
> > Well, if binary compatibility could be maintained at least on the bug fix
> > branch, it would be good already. 
> > 
> > But if what Jacques says is true, and the binary compatibility is only broken
> > by the way the diggests are calculated, maybe there may be a
> > solution there ?
> > 
> > Or is the binary-compatibility breakage really needed ? 
> 
> Actually, what I gave is only one possible reason for breakage.
> Another that comes to mind is that .cmx's contain code to be inlined.
> If any file was modified in the standard library (to fix a bug there),
> then there is a good chance that this code changed, and as a result
> the digest will make it binary incompatible.

Oh well.

> Binary compatibility as you get it in C is just a hack: you drop some
> consistency checks, and hope that the user is clever enough to not use
> incompatible libraries. Ocaml chooses the safe way. This could be made
> a bit more resilient, particularly for bytecode, but you would still
> have breakages in the bug fix branch.

What would be nice in this light, would be an exact list of the digests, and
thus the modules, that changed, so we could only rebuild the packages that are
actually affected. That said, such behavior is a major drawback for using
ocaml in real projects, i believe.

> > Anyway, it would be nice if the breakage would at least be announced in the
> > release documentation. Especially if it doesn't touch all the modules and
> > libraries, as was the case for 3.08.2.
> 
> You can safely assume that every new release breaks binary compatibility.
> (I.e. that some digests in the libraries have changed.)

Yep, understood that now, 3.08.2 came as a big surprise though, as we somehow
expected no binary compatibility change for a bug fix release.

But now we know about it, and i will enable the full-rebuild process for the
3.08.3 release, hoping that it will be in time for the debian/sarge release.

Friendly,

Sven Luther


  reply	other threads:[~2005-01-16 18:23 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-13  7:24 [Caml-list] Bug in Unix library on Mac? spiral voice
2005-01-13 16:53 ` Damien Doligez
2005-01-13 18:41   ` binary compatibility of 3.08.3 Stefano Zacchiroli
2005-01-13 23:02     ` [Caml-list] " Jacques Garrigue
2005-01-14 13:36       ` Sven Luther
2005-01-14 15:01         ` Yaron Minsky
2005-01-16 13:25           ` Sven Luther
2005-01-16 13:33             ` Berke Durak
2005-01-16 14:31               ` Sven Luther
2005-01-17  5:52             ` William Lovas
2005-01-15 12:07         ` Xavier Leroy
2005-01-16 13:37           ` Sven Luther
2005-01-16 16:26             ` Jacques Garrigue
2005-01-16 18:23               ` Sven Luther [this message]
2005-01-20  5:53                 ` Jacques Garrigue
2005-01-20  8:59                   ` Sven Luther
2005-01-16 21:08             ` Damien Doligez
2005-01-16 22:27               ` Sven Luther
2005-01-14 15:25       ` Marcin 'Qrczak' Kowalczyk
2005-01-27 15:40       ` Christophe TROESTLER
2005-01-30  6:11         ` Sven Luther
2005-01-30 11:12           ` Christophe TROESTLER
2005-01-30 15:28           ` Stefan Monnier
2005-01-31  7:09             ` Sven Luther

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050116182303.GA32427@pegasos \
    --to=sven.luther@wanadoo.fr \
    --cc=caml-list@inria.fr \
    --cc=debian-ocaml-maint@lists.debian.org \
    --cc=garrigue@math.nagoya-u.ac.jp \
    /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