From: "Daniel Bünzli" <daniel.buenzli@erratique.ch>
To: Adrien Nader <adrien@notk.org>
Cc: Goswin von Brederlow <goswin-v-b@web.de>, caml-list@inria.fr
Subject: Re: [Caml-list] About contributions to the Standard Library
Date: Mon, 11 Jul 2016 21:36:39 +0100 [thread overview]
Message-ID: <41630DAB0C6544EE89B248F7EFBB25FE@erratique.ch> (raw)
In-Reply-To: <20160711183451.GA20894@notk.org>
Le lundi, 11 juillet 2016 à 19:34, Adrien Nader a écrit :
> I see it as important because things get a bit sad if your code never
> reaches end-users.
[...]
> If you look around, you'll see that many large-ish projects have shifted
> to time-based releases.
[...]
> Releasing stable versions
> is a time-consuming work not matter the topic and I don't find it sane
> to not take them into account.
I'm not sure we are understanding each other here.
1. I think it's precisely the purpose of a system package manager to cut consistent releases of OCaml and OPAM packages in order to deliver end-user *applications* (e.g. unison). Once this is done you get to install these applications using this consistent system.
2. The fact that people are doing time-based releases is irrelevant to this discussion. What is relevant is how long these releases are supported, the constraints they impose and for which purpose they are used.
3. I don't know where you got the idea that I was somehow against stable versions or that I didn't want to take them into account.
So to sum up while 1. is fine. It seems dubious to me to use these system packages in order to do application *development*, and hence to require current developments to remain compatible with these versions, especially if they are long-lasting without the possibility of bumping their version number beyond bug fixes.
Best,
Daniel
next prev parent reply other threads:[~2016-07-11 20:37 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-21 11:56 Damien Doligez
2016-06-21 15:48 ` Gabriel Scherer
2016-06-21 15:54 ` [Caml-list] About "precise (formal) things that can be said about properties of certain interfaces" David MENTRE
2016-06-21 19:11 ` Gabriel Scherer
2016-06-21 20:06 ` Jesper Louis Andersen
2016-06-22 15:33 ` [Caml-list] About contributions to the Standard Library Junsong Li
2016-06-22 21:31 ` Alain Frisch
2016-07-07 10:26 ` Daniel Bünzli
2016-07-08 14:01 ` Alain Frisch
2016-07-08 14:37 ` Daniel Bünzli
2016-07-11 8:55 ` Goswin von Brederlow
2016-07-11 9:43 ` Daniel Bünzli
2016-07-11 9:48 ` Adrien Nader
2016-07-11 10:28 ` Daniel Bünzli
2016-07-11 18:34 ` Adrien Nader
2016-07-11 20:36 ` Daniel Bünzli [this message]
2016-07-11 9:49 ` Goswin von Brederlow
2016-07-12 18:32 ` Ian Zimmerman
2016-07-12 19:01 ` Gabriel Scherer
2016-07-12 21:26 ` Ian Zimmerman
2016-07-12 22:35 ` Gabriel Scherer
2016-07-12 23:20 ` Ian Zimmerman
2016-06-27 9:09 ` Goswin von Brederlow
2016-06-27 11:19 ` Gerd Stolpmann
2016-06-27 13:21 ` Gabriel Scherer
2016-06-30 11:08 ` Goswin von Brederlow
2016-06-30 15:52 ` Gabriel Scherer
2016-06-30 10:59 ` Goswin von Brederlow
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=41630DAB0C6544EE89B248F7EFBB25FE@erratique.ch \
--to=daniel.buenzli@erratique.ch \
--cc=adrien@notk.org \
--cc=caml-list@inria.fr \
--cc=goswin-v-b@web.de \
/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