From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr 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 ABD2081799 for ; Thu, 25 Jul 2013 07:32:13 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of adrien@notk.org) identity=pra; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of adrien@notk.org designates 91.121.71.147 as permitted sender) identity=mailfrom; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; 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@nautica.notk.org) identity=helo; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="postmaster@nautica.notk.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAHS38FFbeUeT/2dsb2JhbABagwaDKGm6USN1FnSCHAgBAQQBIw8BRgULCxgCAgUTDgICDwUYhjqCFAqoMpFMgSiOVQeCXw4lbgOXXgGRTYMWOg X-IPAS-Result: AlcFAHS38FFbeUeT/2dsb2JhbABagwaDKGm6USN1FnSCHAgBAQQBIw8BRgULCxgCAgUTDgICDwUYhjqCFAqoMpFMgSiOVQeCXw4lbgOXXgGRTYMWOg X-IronPort-AV: E=Sophos;i="4.89,740,1367964000"; d="scan'208";a="22185795" Received: from nautica.notk.org ([91.121.71.147]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 25 Jul 2013 07:32:13 +0200 Received: by nautica.notk.org (Postfix, from userid 1003) id 4AD27C009; Thu, 25 Jul 2013 07:32:12 +0200 (CEST) Date: Thu, 25 Jul 2013 07:32:12 +0200 From: Adrien Nader Cc: Ocaml Mailing List Message-ID: <20130725053212.GB2066@notk.org> References: <1374669368.25411.5@samsung> <1B6BB035-9909-4F0C-9DEA-F713B977A467@ocamlpro.com> <7F8931D5-E65D-49EB-B54D-A50716F3EFDD@recoil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Caml-list] GODI is shutting down On Wed, Jul 24, 2013, Daniel Bünzli wrote: > Le mercredi, 24 juillet 2013 à 19:23, Markus Mottl a écrit : > > I'm not going that far yet, I'll just wait and see whether Oasis will > > improve to the point where the hard stuff gets easy enough, or, who > > knows, until something even better comes along. But I really do like > > the idea of having a standardized packaging file within the package. > > Agreed, but for me that file was renamed from `_oasis` to `opam`. It has everything, the metadata, the (optional) dependencies and the build instructions. But that doesn't match. OPAM is a source-based package manager. It needs the compiler to work. Maybe that it will support binary packages but today it isn't there and it will take some time for this feature to appear of course and then the packages will have to be made, and there's the question of who or what will be the builder and whether it can be trusted or not. OPAM will not replace a distribution's package manager. It's good for people who develop or are somehow involved in the language but for everyone else, what they want and need is packages for their distribution. That was the goal for oasis, that makes no sense as a goal for opam. > Contrary to what Adrian Nader suggested a few emails ago pinning is absolutely not a bad idea in general. I agree with him that using unreleased software is by definition a bad idea and I'm a strong advocate of semantic versioning and formal release processes. However the pin mechanism --- which can pin to a specific *commit* --- combined with the root `opam` file in your repo, allows to: ask someone to test a fix, quickly propagate a security fix, issue a release candidate, evaluate the damage an incompatible release would entail, etc. all this without having to disturb the whole stable eco-system and with minimal energy dissipation. I probably expressed myself poorly. Pinning is good when you want to do a specific task at a specific time. It's not good when you start pinning several things at once and keep them that way for a long time. In other words, what I meant was that pinning of several repos was not a substitute for releases. -- Adrien Nader