From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 57099BC8C for ; Sun, 16 Jan 2005 23:28:03 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j0GMS2ZN006699 for ; Sun, 16 Jan 2005 23:28:02 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA30754 for ; Sun, 16 Jan 2005 23:28:02 +0100 (MET) Received: from smtp3.wanadoo.fr (smtp3.wanadoo.fr [193.252.22.28]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j0GMS2ZC008253; Sun, 16 Jan 2005 23:28:02 +0100 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0302.wanadoo.fr (SMTP Server) with ESMTP id EDE0F1C00B26; Sun, 16 Jan 2005 23:28:01 +0100 (CET) Received: from pegasos (AStrasbourg-251-1-59-193.w82-126.abo.wanadoo.fr [82.126.135.193]) by mwinf0302.wanadoo.fr (SMTP Server) with ESMTP id B4DF71C00B19; Sun, 16 Jan 2005 23:28:01 +0100 (CET) X-ME-UUID: 20050116222801741.B4DF71C00B19@mwinf0302.wanadoo.fr Received: from luther by pegasos with local (Exim 4.34) id 1CqIs0-00015z-CO; Sun, 16 Jan 2005 23:27:40 +0100 Date: Sun, 16 Jan 2005 23:27:40 +0100 To: Damien Doligez Cc: Sven Luther , debian-ocaml-maint@lists.debian.org, caml users Subject: Re: [Caml-list] binary compatibility of 3.08.3 Message-ID: <20050116222740.GA4158@pegasos> Mail-Followup-To: Damien Doligez , Sven Luther , debian-ocaml-maint@lists.debian.org, caml users References: <99C2C114-6583-11D9-B72B-000D9345235C@inria.fr> <20050113184137.GA24040@fistandantilus.takhisis.org> <20050113.150239.95895778.garrigue@math.nagoya-u.ac.jp> <20050114133632.GA4923@pegasos> <20050115120719.GB11037@yquem.inria.fr> <20050116133724.GB1467@pegasos> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Sven Luther X-Miltered: at concorde with ID 41EAEA72.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 41EAEA72.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 binary:01 sven:01 luther:01 sven:01 luther:01 damien:01 wrote:01 wrote:01 ocaml:01 bugfix:01 ocaml:01 dependencies:01 autobuilders:01 binary:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: 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