Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: [Caml-list] Bug in Unix library on Mac?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Sven Luther <sven.luther@w...>
Subject: Re: [Caml-list] binary compatibility of 3.08.3
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