From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 6EEA0E01D2 for ; Mon, 4 Jan 2021 08:59:36 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=fabrice.le_fessant@origin-labs.com; spf=Pass smtp.mailfrom=fabrice.le_fessant@origin-labs.com; spf=None smtp.helo=postmaster@relay12.mail.gandi.net Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of fabrice.le_fessant@origin-labs.com) identity=pra; client-ip=217.70.178.232; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="fabrice.le_fessant@origin-labs.com"; x-sender="fabrice.le_fessant@origin-labs.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of fabrice.le_fessant@origin-labs.com designates 217.70.178.232 as permitted sender) identity=mailfrom; client-ip=217.70.178.232; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="fabrice.le_fessant@origin-labs.com"; x-sender="fabrice.le_fessant@origin-labs.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@relay12.mail.gandi.net) identity=helo; client-ip=217.70.178.232; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="fabrice.le_fessant@origin-labs.com"; x-sender="postmaster@relay12.mail.gandi.net"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AdWX99BPgwne9cmavyfsl6mtUPXoX/o7sNwtQ0KIM?= =?us-ascii?q?zox0I/v4rarrMEGX3/hxlliBBdydt6sbzbCN6eu8CCQp2tWoiDg6aptCVhsI24?= =?us-ascii?q?09vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7?= =?us-ascii?q?Ovr6GpLIj8Swyuu+54Dfbx9HiTagY75+Ngu6oAvPusUZjoZvLrs6xwfUrHdPZ+?= =?us-ascii?q?lY335jK0iJnxb76Mew/Zpj/DpVtvk86cNOUrj0crohQ7BAAzsoL2465MvwtRne?= =?us-ascii?q?VgSP/WcTUn8XkhVTHQfI6gzxU4rrvSv7sup93zSaPdHzQLspVzmu87tnRRn1gy?= =?us-ascii?q?ocKTU37H/YhdBxjKJDoRKuuRp/w5LPYIqIMPZyZ77Rcc8GSWZEWMtaSi5PDZ6m?= =?us-ascii?q?b4YXAOUBM+RXoYnzqVUNsBWwGxWjCfjzyjNUnHL6wbE23/gjHAzAwQcuH8gOsH?= =?us-ascii?q?PRrNjtNKkdS/u6zLPJzTrfcfxdxDHz55bVeR4hv/6MRqlwftDXyUkzCgjIiVuQ?= =?us-ascii?q?ppb+MDOP1+QCr3aU4/BkVe2xk2EnpR9+oiO0xsg2jInJmpkYylfe9SV4z4Y1JN?= =?us-ascii?q?u4RFd/YdG+C5RQrDuWOJdxQsMnWmxlvjsxxbIat5ChZicK1IgnyADFa/yBa4WF?= =?us-ascii?q?4BbuWPuTLDp6hX9rdrCyihKv/US9yuDyWM253lZUoydBndTBt3EA2gLd58aIRP?= =?us-ascii?q?Vw4lmt1DST2gzN9+xJJUQ5mKzGIJAi2r49joQfvVnBEyPsmkj6kLWaelgm9+Wr?= =?us-ascii?q?8ejrfLvrqoGEO4Nqlg3zNr4il8+/DOgiLAQCQmuW9f682bDt+0DyXa9Egecskq?= =?us-ascii?q?bDtZDXPcQbqbC9Aw9Syosj8QiwDzO839UYgHULMkhJeBedgIjoP1HCOv/4Au25?= =?us-ascii?q?g1uxkTdn3fbGMaP9ApnVL3jDlqnufapl5kJC1QY+z8pT6pBIBr0bPf7+WEz8uM?= =?us-ascii?q?bGAhI3LQC42+PnB8981oMaV2KPGKiZMKbKvF+G/O0gOPOMZI4JtznjMfQl4+Dh?= =?us-ascii?q?gmc3mVADZqmpxoEYaHakHvl9JEWZe3vsgtgAEWcMpwY+SPblh0aZUTJJe3myWK?= =?us-ascii?q?c86ikhCI26FYfDWpytgLuZ0SinBJJWY2RGBkmIEXfpbIWER+wBaDmSI89kijwL?= =?us-ascii?q?T6KtS44n1RG0tQ/10aBrLuTO+n5QiZW28dFx7OrXkFkX/CB9C8eUmzWISmhol2?= =?us-ascii?q?cLThc52al+pQp2zVLVgoZihPkNO9VZ/fJCX08eONbywvdhAtbuElbPd92TSV2r?= =?us-ascii?q?BNGrNj88Vck4xcMmZFx8FNSkyxTK1THsCLgQwe/YTKco+77RiiCib/12zGzLge?= =?us-ascii?q?x41wF/E5l/cFa+j6s6zDD9QovAkkGXjaGvLPtO2zTM+2aFiG6HtloeWwl1A/yc?= =?us-ascii?q?ASIvI3DOpNG83XvsCqe0AO14YAxbyMGDLO5OY9fyy15BQaW7YYmMUyeKg261QC?= =?us-ascii?q?2w6PaMYY7tITlPxijZAVldyUYW9HeCcwc3ACug5WTTEG42GA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgD3yfJfh+iyRtligQmFSDIuhD+RL?= =?us-ascii?q?gOKGpIdCwEDAQ0vBAEBhEoCgW8CHQcBBDQTAhABAQUBAQECAQMDBAETAQEBAQ0?= =?us-ascii?q?LCQgbDoV0gjgpAYMSAQEEEhFWEAsLAwoCAiYCAiEBEgEFARwGEyKDBIJWAy4Eo?= =?us-ascii?q?xiBBD2LNIEyiA0NFU2BQoEOKoVhEjyGeiaCG4FHgjUuPoIbhTuCYASCRAEBXhg?= =?us-ascii?q?JBQ8SP2FLDhk/txw5WAeCeZY7hR0igymfJ5YNjAaOMSaEbRAjgUpNgS1NI1AxB?= =?us-ascii?q?oIyUBkNjjuOMEAzNwIGCgEBAwmOGgEB?= X-IPAS-Result: =?us-ascii?q?A0AfAgD3yfJfh+iyRtligQmFSDIuhD+RLgOKGpIdCwEDAQ0?= =?us-ascii?q?vBAEBhEoCgW8CHQcBBDQTAhABAQUBAQECAQMDBAETAQEBAQ0LCQgbDoV0gjgpA?= =?us-ascii?q?YMSAQEEEhFWEAsLAwoCAiYCAiEBEgEFARwGEyKDBIJWAy4EoxiBBD2LNIEyiA0?= =?us-ascii?q?NFU2BQoEOKoVhEjyGeiaCG4FHgjUuPoIbhTuCYASCRAEBXhgJBQ8SP2FLDhk/t?= =?us-ascii?q?xw5WAeCeZY7hR0igymfJ5YNjAaOMSaEbRAjgUpNgS1NI1AxBoIyUBkNjjuOMEA?= =?us-ascii?q?zNwIGCgEBAwmOGgEB?= X-IronPort-AV: E=Sophos;i="5.78,473,1599516000"; d="scan'208";a="368942188" X-MGA-submission: =?us-ascii?q?MDE8neDQU5n8QVdxPh41mFua5IDJ/dwZjlmBR4?= =?us-ascii?q?21sGJ7pZj0ZwYk9Nw3xLYvJgUYtqeeC5ABMBwLDL81+0p9FM054P/GZd?= =?us-ascii?q?LFb3Epb+FqUoU+73MzMWuAp/ZLxA8JFkyVPfmKRa3cW3uBXZjVMN7Cyi?= =?us-ascii?q?+oGZxh5iOkaYzQiaDdxrqkSw=3D=3D?= Received: from relay12.mail.gandi.net ([217.70.178.232]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jan 2021 08:59:35 +0100 Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) (Authenticated sender: fabrice.le_fessant@origin-labs.com) by relay12.mail.gandi.net (Postfix) with ESMTPSA id DE8F4200003 for ; Mon, 4 Jan 2021 07:59:34 +0000 (UTC) Received: by mail-ej1-f53.google.com with SMTP id 6so35654145ejz.5 for ; Sun, 03 Jan 2021 23:59:34 -0800 (PST) X-Gm-Message-State: AOAM5303ZLy2Ps5H8hQI8C9wEoAc0Rlbz3RgNji6LfMEz4FdtLfaYYok pQi+RGaHGHMKDFQ2S59KQVyyr2oGcTQjwH3GQNI= X-Google-Smtp-Source: ABdhPJzQAnGqBgU8YL8cqerKm4mzWZk9pC1Foo6aBrLg8/xlyyHO2FIsMOxl75RiRQ0KOYdr5U8oYSPpyvHkK9Zx9cw= X-Received: by 2002:a17:906:2e82:: with SMTP id o2mr66369245eji.106.1609747174345; Sun, 03 Jan 2021 23:59:34 -0800 (PST) MIME-Version: 1.0 References: <101ac12b-89c3-4803-6fcb-288949a164cd@web.de> <86im8dgrtm.fsf@gmail.com> In-Reply-To: <86im8dgrtm.fsf@gmail.com> From: Fabrice Le Fessant Date: Mon, 4 Jan 2021 08:59:23 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Malcolm Matalka Cc: Markus Elfring , Ocaml Mailing List Content-Type: text/plain; charset="UTF-8" Subject: Re: [Caml-list] Determining compatibility for evolving programming interfaces Hi, In a few libraries I have been involved recently in the development, we decided to export the interface under a module `V1`, with the principle that we shouldn't make incompatible changes to V1, or switch to a new interface V2, keeping V1 as it was. Then, the user can use `open Library.V1` to access the interface and have more guarantees that it will not break too often in the future. As Malcom wrote, we assume that some changes in the interface are ok without changing the version, like adding an optional argument or a field in a record, though it is possible for such changes to break other packages (if the function is passed as an argument for example, or if warn-error is enabled). For now, it is just an experiment, made also possible by the fact that these libraries are "one-module" libraries, and we will see in the future if it was a good idea or not. -- Fabrice On Mon, Jan 4, 2021 at 7:05 AM Malcolm Matalka wrote: > > > Markus Elfring writes: > > > Hello, > > > > OCaml is also an instance of a programming language where type inference belongs > > to core functionality. The usage of various data types will evolve in several > > programming interfaces. > > > > * How do you think about to check if API revisions are still > > compatible there? > > IME, this is really up to the author and I don't know if there is a > single correct answer. Usually people define it as if, between > versions, the function does the same thing given the same inputs. The > common question is: what about bug fixes? Whether or not the fix is to > document the bug fix because people depend on it or break it is up to > the developer. > > > > > * Which kind of variations can be occasionally tolerated in interface > > descriptions? > > From a technical perspective, the following are safe: > > - Adding optional parameters > > - Supporting more polymorphic variant types. > > - Returning fewer polymorphic variant types. > > - Probably similar with objects but I don't have much experience with > objects. > > From a human perspective, I tend to be OK with breaking changes if the > cause a compilation failure, that way the developer is forced to > understand the change and update it. If an interface is sufficiently > changed, I might just make a new library (library2) that implements the > change, especially if the core functionality is staying the same and I'm > mostly changing the feel of the library. That's also nice if you're > comparing two implementations and want to have them side-by-side. > > I, personally, find semantic versioning to be not very useful because, > at the end of the day, it requires humans to make decisions about if > their changes fit into the various categories of change, and by our > nature we don't like to increment the major version for some reason. > I've come across numerous libraries in opam that break even compiling > despite not changing the major. > > > > > > > I would appreciate your advices. > > > > Regards, > > Markus