caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Sven Luther <sven.luther@wanadoo.fr>
To: Damien Doligez <damien.doligez@inria.fr>
Cc: Sven Luther <sven.luther@wanadoo.fr>,
	debian-ocaml-maint@lists.debian.org,
	caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] binary compatibility of 3.08.3
Date: Sun, 16 Jan 2005 23:27:40 +0100	[thread overview]
Message-ID: <20050116222740.GA4158@pegasos> (raw)
In-Reply-To: <B4A8D336-6802-11D9-B72B-000D9345235C@inria.fr>

On Sun, Jan 16, 2005 at 10:08:01PM +0100, Damien Doligez wrote:
> On Jan 16, 2005, at 14:37, Sven Luther wrote:
> 
> >Also, we are hoping to release soon, and the debian release manager 
> >will
> >assuredly not wait for ocaml stuff to rebuild if it is the only thing 
> >missing.
> >The release delay have hurt enough as it is.
> [...]
> >Just forgetting about the fix and include it in the next version of 
> >sarge is
> >the only sane possibility then.
> 
> I don't see it as a big problem if you are lagging by one bugfix 
> version.
> The differences are small anyway, and it's not like 3.08.2 is horribly
> broken.

Yep, we are going to try to make it, it should be possible to hasten the
process some if we stage the uploads just right, and implement some smart
(build) dependency tree travelling to make sure that we forget no package. 
The matter is complicated because ocaml uses a virtual ocaml-3.08 package as
build-dependency, to be able to make sure we don't have a package builded
against a binary-incompatible version. This will become ocaml-3.08.3, but the
debian tools have trouble with dependencies on virtual packages, especially
the autobuilders. Oh well, we will handle.

> >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.
> 
> I would have announced it if I had known about it.  From now on, I will 

Ah, so we were not the only one surprised :)

> put
> a reminder about binary compatibility in the release notes for each 
> bugfix
> release.

Cool.

> >That said, such behavior is a major drawback for using
> >ocaml in real projects, i believe.
> 
> I'd say it's a drawback of blind upgrading, which nobody does in a
> real project anyway.

Well, it was a bug fix release. I looked over the changelog, and everything
seemed reasonable in it. I did not look over the actual source code, and
nothing hinted at binary compatibility problems in the changelog, or maybe i
just missed it. If each individual changelog entry which breaks binary
compatibility listed the affected modules, that would be a great solution to
this problem.

Friendly,

Sven Luther


  reply	other threads:[~2005-01-16 22:28 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
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 [this message]
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=20050116222740.GA4158@pegasos \
    --to=sven.luther@wanadoo.fr \
    --cc=caml-list@inria.fr \
    --cc=damien.doligez@inria.fr \
    --cc=debian-ocaml-maint@lists.debian.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 NNTP newsgroup(s).